ఇంజనీరింగ్ టీమ్లు REST అంతరించిపోయిందా లేదా gRPC మిగిలినవన్నీ పనికిరాకుండా చేసిందా అని వాదించుకుంటూ మధ్యాహ్నాలను వృథా చేస్తూనే ఉంటారు. ఆ చర్చ అసలు విషయం నుండి పక్కదారి పడుతోంది. మీరు ఉత్తమమైన ప్రోటోకాల్ను ఎంచుకోవడం లేదు. మీరు సరైన బౌండరీని (boundary) ఎంచుకుంటున్నారు. మీ Kubernetes క్లస్టర్ లోపల అద్భుతంగా పనిచేసే ప్రోటోకాల్, మీరు దానిని వేల సంఖ్యలో ఉన్న బాహ్య డెవలపర్లకు అందించినప్పుడు విఫలమవుతుంది. మీ మొబైల్ యాప్ యొక్క విలువైన బ్యాండ్విడ్త్ను ఆదా చేసే ప్రోటోకాల్, మీరు దానిని ఏవైనా పబ్లిక్ క్వెరీలకు (public queries) అనుమతిస్తే మీ ఇన్ఫ్రాస్ట్రక్చర్ను దెబ్బతీస్తుంది. ఈ నిర్ణయాన్ని ఒక సాంకేతిక ప్రజాదరణ పోటీలా భావిస్తే, మీ టీమ్లోని ప్రస్తుత సభ్యులందరూ వెళ్ళిపోయిన తర్వాత కూడా ఉండే ఆర్కిటెక్చరల్ డెట్ (architectural debt) ను మీరు సృష్టించినట్లవుతుంది.
బౌండరీ సూత్రం (The Boundary Principle)
ఆర్కిటెక్చర్ అనేది ట్రేడ్-ఆఫ్స్ (trade-offs) గురించి, విజేతల గురించి కాదు. సరైన ప్రశ్న "ఏది వేగంగా ఉంటుంది?" లేదా "ఏది కొత్తది?" అని కాదు. అది "మరో వైపు ఎవరు ఉన్నారు, మరియు వారు దేనిని నియంత్రిస్తున్నారు?" అని ఉండాలి. ప్రోటోకాల్స్ అనేవి బౌండరీ ఆబ్జెక్ట్లు. తప్పు ప్రోటోకాల్ను ఎంచుకోవడం వల్ల కేవలం మీ వేగం తగ్గడమే కాదు, అది మీ సిస్టమ్లో సంవత్సరాల తరబడి ఉండే తప్పులకు దారితీస్తుంది.
పబ్లిక్ APIs: REST బోరింగ్ కాదు, అది బాధ్యతాయుతమైనది
మీ వినియోగదారుడు మీరు ఎప్పుడూ చూడని బాహ్య డెవలపర్ అయినప్పుడు, మీ API కేవలం ఒక ఇంటర్ఫేస్ మాత్రమే కాదు, అది ఒక ఉత్పత్తి (product). ఆ డెవలపర్ అర్ధరాత్రి రెండు గంటల సమయంలో కేవలం curl మరియు Postman collection మాత్రమే ఉపయోగించి డీబగ్గింగ్ చేస్తూ ఉంటారు. వారు తమ మొదటి కాల్ విజయవంతం కావడానికి ముందే ఒక కస్టమ్ క్లయింట్ లైబ్రరీని ఇన్స్టాల్ చేయాల్సి వచ్చినా లేదా ఒక స్కీమా లాంగ్వేజ్ను నేర్చుకోవాల్సి వచ్చినా, మీరు ఇప్పటికే వారిని కోల్పోయినట్లే.
ఇక్కడ REST మనుగడ సాగిస్తోంది ఎందుకంటే అది వెబ్ యొక్క ప్రాణం. HTTP మెథడ్స్, స్టేటస్ కోడ్లు మరియు JSON అనేవి అందరికీ తెలిసిన భాషలు. క్యాషింగ్ (Caching) అనేది అదనంగా చేసే పని కాదు; అది ఇప్పటికే ఉన్న ఇన్ఫ్రాస్ట్రక్చర్. బ్రౌజర్లు, CDNs మరియు ఎడ్జ్ క్యాచెస్ (edge caches) Cache-Control హెడర్లు మరియు ETag వాలిడేషన్ను సహజంగానే అర్థం చేసుకుంటాయి. మీరు ఒక ప్రామాణిక CDN వెనుక REST APIని ఉంచి, ఒక్క లైన్ క్యాషింగ్ లాజిక్ కూడా రాయకుండానే తక్షణ బ్యాండ్విడ్త్ ఆదా చేయవచ్చు. పబ్లిక్ ట్రాఫిక్ అంచనా వేయలేనిదిగా ఉన్నప్పుడు మరియు మీ క్లౌడ్ నుండి వెళ్లే ప్రతి గిగాబైట్కు మీరు డబ్బు చెల్లిస్తున్నప్పుడు, ఇది చాలా ముఖ్యం.
దీనికి విరుద్ధంగా, GraphQL పబ్లిక్ బౌండరీ వద్ద భారీ పన్ను (heavy tax) లాంటిది. ఒకే ఒక్క అజాగ్రత్త లేదా దుర్మార్గపు క్వెరీ మీ డేటాబేస్ను దెబ్బతీయకుండా ఉండటానికి, పబ్లిక్ GraphQL ఎండ్పాయింట్లకు క్వెరీ కాస్ట్ అనాలిసిస్ (query cost analysis), డెప్త్ లిమిటింగ్ (depth limiting) మరియు కాంప్లెక్సిటీ స్కోరింగ్ అవసరం. మీరు కేవలం ఒక APIని మాత్రమే పంపిణీ చేయడం లేదు; మీరు ఒక క్వెరీ ఎగ్జిక్యూషన్ ఇంజిన్, రేట్-లిమిటింగ్ స్ట్రాటజీ మరియు కంప్యూట్ బిల్లింగ్ మోడల్ను నిర్మిస్తున్నారు. మీకు అతిపెద్ద ప్లాట్ఫారమ్ల వంటి ఆపరేషనల్ సామర్థ్యం లేకపోతే, పబ్లిక్ సర్ఫేస్ ఏరియా కోసం ఆ ఓవర్హెడ్ చాలా ప్రమాదకరం. REST డిఫాల్ట్గా గార్డ్రైల్స్ను (guardrails) ఏర్పాటు చేస్తుంది. ప్రతి ఎండ్పాయింట్ ఒకే పని చేస్తుంది. వినియోగదారులు మీరు అందించే దానిని మాత్రమే పొందుతారు, వారు ఊహించిన దేన్నైనా కాదు.
ఇంటర్నల్ సర్వీసెస్: మొత్తం పైప్లైన్ను నియంత్రించండి
మీ సంస్థ లోపల, సంభాషణ మారుతుంది. క్లయింట్ మరియు సర్వర్ రెండింటినీ మీరు నియంత్రిస్తారు. కాల్ చైన్లోని ప్రతి సర్వీస్ కోసం మీరు టెక్నాలజీ స్టాక్ను నిర్ణయించవచ్చు. ఇక్కడే gRPC తన విలువను చాటుకుంటుంది.
మొదట, JSONని పవిత్రమైనదిగా చూడటం ఆపండి. Protocol Buffers, JSON కంటే సుమారు మూడు రెట్లు వేగంగా సీరియలైజ్ అవుతాయి. ఫార్మాట్ బైనరీ కాబట్టి పేలోడ్లు (payloads) చిన్నవిగా ఉంటాయి. బిజీగా ఉన్న ఇంటర్నల్ నెట్వర్క్లో, ఆ మిల్లీసెకన్లు మరియు మెగాబైట్లు నిజమైన డబ్బుగా మరియు తక్కువ లేటెన్సీగా (lower tail latency) మారుతాయి. అంతకంటే ముఖ్యంగా, Protobuf మీకు ఒక కఠినమైన కాంట్రాక్ట్ను ఇస్తుంది. మీరు ఫీల్డ్ టైప్ను మార్చినప్పుడు లేదా మెసేజ్ను రీనేమ్ చేసినప్పుడు, ఆ లోపం కంపైల్ టైమ్లోనే తెలుస్తుంది, ప్రొడక్షన్లో అర్ధరాత్రి డౌన్స్ట్రీమ్ సర్వీస్ ఎర్రర్స్ ఇస్తుందన్న భయం ఉండదు.
gRPC, HTTP/2 పై నడుస్తుంది, కాబట్టి మీకు హెడర్ కంప్రెషన్, మల్టీప్లెక్స్డ్ స్ట్రీమ్స్ మరియు రియల్ స్ట్రీమింగ్ సెమాంటిక్స్ లభిస్తాయి. మీరు సర్వీసుల మధ్య హై-త్రూపుట్ ఈవెంట్లను పంపిస్తున్నా లేదా రియల్ టైమ్ అప్డేట్లను పంపిస్తున్నా, సర్వర్-సైడ్ మరియు బైడైరెక్షనల్ స్ట్రీమింగ్ అనేవి నేటివ్ ఫీచర్లు, అవి కేవలం రిక్వెస్ట్-రెస్పాన్స్ ఫ్రేమ్వర్క్పై అతికించిన పాత పద్ధతులు కావు.
ఇక్కడ ఒక ముఖ్యమైన విషయం ఉంది: gRPCని నేరుగా బ్రౌజర్కు అనుసంధానించకండి. బ్రౌజర్ నెట్వర్కింగ్ మోడల్స్ gRPC ఆశించిన విధంగా HTTP/2ని ఉపయోగించలేవు. బ్రౌజర్ బ్యాకెండ్తో మాట్లాడటం కోసం మీరు grpc-web మరియు Envoy వంటి ప్రాక్సీలను మీ స్టాక్కు జోడించాల్సి వస్తుంది. అది బగ్ కాదు; అది ఒక బౌండరీ సిగ్నల్. gRPCని మీ ఫైర్వాల్ వెనుక, ఒకదానికొకటి నమ్మకమైన సర్వీసుల మధ్య ఉంచండి మరియు దాని డీబగ్గింగ్ సంక్లిష్టతను వేగం కోసం మీరు చెల్లించే ధరగా భావించండి. JSON లాగా బైనరీ పేలోడ్లు లాగ్ ఫైల్లో చూడటానికి సులభంగా ఉండవు.
కాంప్లెక్స్ UIలు మరియు మొబైల్: GraphQL యొక్క ప్రత్యేకత
ఆధునిక మొబైల్ స్క్రీన్లు వివిధ భాగాల కలయిక. ఒక వ్యూ (view) కి యూజర్ ప్రొఫైల్ అవసరం కావచ్చు,
