એન્જિનિયરિંગ ટીમો હજી પણ આખી બપોર એ ચર્ચા કરવામાં બગાડે છે કે REST મરી ગયું છે કે gRPC એ બધું જ નકામું કરી દીધું છે. આ ચર્ચા મુખ્ય મુદ્દાને ચૂકી જાય છે. તમે શ્રેષ્ઠ પ્રોટોકોલ પસંદ નથી કરી રહ્યા. તમે યોગ્ય સીમા (boundary) પસંદ કરી રહ્યા છો. તમારા Kubernetes ક્લસ્ટરની અંદર જે પ્રોટોકોલ ઉત્તમ કામ કરે છે, તે જ્યારે તમે હજારો બાહ્ય ડેવલપર્સને સોંપશો ત્યારે ગૂંગળાઈ જશે. જે તમારા મોબાઈલ એપ માટે કિંમતી બેન્ડવિડ્થ બચાવે છે, તે જો તમે અસંગત પબ્લિક ક્વેરીઝ માટે ખુલ્લું મૂકી દેશો તો તમારા ઇન્ફ્રાસ્ટ્રક્ચરને બરબાદ કરી દેશે. જો તમે આ નિર્ણયને ટેકનોલોજીની લોકપ્રિયતાની સ્પર્ધા તરીકે જોશો, તો તમે એવું આર્કિટેક્ચરલ દેવું (architectural debt) ઊભું કરશો જે તમારી ટીમની વર્તમાન સભ્યતા કરતા પણ લાંબુ ચાલશે.
સીમાનો સિદ્ધાંત (The Boundary Principle)
આર્કિટેક્ચર એ ટ્રેડ-ઓફ્સ (trade-offs) વિશે છે, વિજેતાઓ વિશે નહીં. સાચો પ્રશ્ન ક્યારેય "કયું સૌથી ઝડપી છે?" અથવા "કયું સૌથી નવું છે?" હોતો નથી. તે છે "વાયરની બીજી બાજુએ કોણ બેઠું છે, અને તેઓ શું નિયંત્રિત કરે છે?" પ્રોટોકોલ્સ એ સીમાના ઓબ્જેક્ટ્સ (boundary objects) છે. ખોટો પ્રોટોકોલ પસંદ કરવાથી માત્ર તમારી ગતિ ધીમી નથી પડતી, પરંતુ તે વર્ષો સુધી તમારી સિસ્ટમમાં ભૂલોને જડ કરી દે છે.
પબ્લિક APIs: REST કંટાળાજનક નથી, તે જવાબદાર છે
જ્યારે તમારો વપરાશકર્તા એવો બાહ્ય ડેવલપર હોય જેને તમે ક્યારેય મળ્યા નથી, ત્યારે તમારું API માત્ર એક ઇન્ટરફેસ નથી, પણ એક પ્રોડક્ટ છે. તે ડેવલપર વહેલી સવારે બે વાગ્યે માત્ર curl અને Postman કલેક્શનના સહારે ડિબગિંગ કરી રહ્યો હોય છે. જો તેમને તેમની પ્રથમ સફળ કોલ કરતા પહેલા કસ્ટમ ક્લાયન્ટ લાઇબ્રેરી ઇન્સ્ટોલ કરવી પડે અથવા સ્કીમા લેંગ્વેજ શીખવી પડે, તો તમે તેમને પહેલેથી જ ગુમાવી દીધા છે.
REST અહીં ટકી રહે છે કારણ કે તે પોતે જ વેબ છે. HTTP મેથડ્સ, સ્ટેટસ કોડ્સ અને JSON એ સામાન્ય ભાષા છે. કેશિંગ (Caching) એ કોઈ વિચાર્યા પછીનો વિચાર નથી; તે પહેલેથી જ અસ્તિત્વમાં રહેલું ઇન્ફ્રાસ્ટ્રક્ચર છે. બ્રાઉઝર્સ, CDNs અને એજ કેશ (edge caches) Cache-Control હેડર્સ અને ETag વેલિડેશનને નેટિવલી સમજે છે. તમે કેશિંગ લોજિકની એક પણ લાઇન લખ્યા વિના, એક સ્ટાન્ડર્ડ CDN પાછળ REST API મૂકી શકો છો અને તરત જ બેન્ડવિડ્થમાં બચત મેળવી શકો છો. જ્યારે પબ્લિક ટ્રાફિક અનિશ્ચિત હોય અને તમે તમારા ક્લાઉડમાંથી બહાર જતી દરેક ગીગાબાઇટ માટે ચૂકવણી કરી રહ્યા હોવ, ત્યારે આ બાબત ખૂબ મહત્વની છે.
તેનાથી વિપરીત, GraphQL પબ્લિક સીમા પર મોટો ટેક્સ (tax) લાવે છે. પબ્લિક GraphQL એન્ડપોઇન્ટ્સને ક્વેરી કોસ્ટ એનાલિસિસ, ડેપ્થ લિમિટિંગ અને કોમ્પ્લેક્સિટી સ્કોરિંગની જરૂર પડે છે જેથી એક બેદરકાર અથવા દુષ્ટ (malicious) ક્વેરી તમારા ડેટાબેઝને તોડી ન નાખે. તમે માત્ર એક API મોકલી નથી રહ્યા; તમે ક્વેરી એક્ઝિક્યુશન એન્જિન, રેટ-લિમિટિંગ સ્ટ્રેટેજી અને કમ્પ્યુટ બિલિંગ મોડેલ બનાવી રહ્યા છો. જ્યાં સુધી તમારી પાસે મોટા પ્લેટફોર્મ જેવી ઓપરેશનલ ક્ષમતા ન હોય ત્યાં સુધી, પબ્લિક સર્ફેસ એરિયા માટે આ ઓવરહેડ બેદરકાર છે. REST ડિફોલ્ટ રીતે ગાર્ડરેલ્સ (guardrails) સેટ કરે છે. દરેક એન્ડપોઇન્ટ એક જ કામ કરે છે. વપરાશકર્તાઓ બરાબર તે જ મેળવે છે જે તમે ઓફર કરો છો, નહીં કે જે કંઈ પણ તેઓ વિચારી શકે.
ઇન્ટરનલ સર્વિસીસ: આખી પાઇપલાઇન પર તમારું નિયંત્રણ રાખો
તમારી સંસ્થાની અંદર, વાતચીત બદલાય છે. તમે ક્લાયન્ટ અને સર્વર બંનેને નિયંત્રિત કરો છો. તમે કોલ ચેઇનમાં દરેક સર્વિસ માટે ટેકનોલોજી સ્ટેક નક્કી કરી શકો છો. અહીં gRPC ખરેખર ઉપયોગી સાબિત થાય છે.
પ્રથમ તો, JSON ને પવિત્ર માનવાનું બંધ કરો. Protocol Buffers JSON કરતા લગભગ ત્રણ ગણી ઝડપથી સીરીયલાઈઝ થાય છે. પેલોડ્સ (payloads) નાના હોય છે કારણ કે તેનું ફોર્મેટ બાઈનરી છે. વ્યસ્ત ઇન્ટરનલ નેટવર્ક પર, તે મિલીસેકન્ડ્સ અને મેગાબાઇટ્સ વાસ્તવિક નાણાંમાં ફેરવાય છે અને ટેઇલ લેટન્સી (tail latency) ઘટાડે છે. વધુ મહત્વનું છે કે, Protobuf તમને એક સખત કરાર (strict contract) આપે છે. જ્યારે તમે ફિલ્ડ ટાઇપ બદલો છો અથવા મેસેજનું નામ બદલો છો, ત્યારે ભૂલ કમ્પાઇલ ટાઇમ (compile time) પર જ પકડાઈ જાય છે, પ્રોડક્શનમાં વહેલી સવારે ત્રણ વાગ્યે જ્યારે ડાઉનસ્ટ્રીમ સર્વિસ પાર્સ એક્સેપ્શન (parse exceptions) ફેંકવાનું શરૂ કરે ત્યારે નહીં.
gRPC HTTP/2 પર ચાલે છે, તેથી તમને હેડર કમ્પ્રેશન, મલ્ટિપ્લેક્સ્ડ સ્ટ્રીમ્સ અને રિયલ સ્ટ્રીમિંગ સેમેન્ટિક્સ મળે છે. જો તમે સર્વિસીસ વચ્ચે હાઈ-થ્રુપુટ ઇવેન્ટ્સ મોકલી રહ્યા હોવ અથવા રિયલ-ટાઇમ અપડેટ્સ પુશ કરી રહ્યા હોવ, તો સર્વર-સાઇડ અને બાય