பொறியியல் குழுக்கள் REST இறந்துவிட்டதா அல்லது gRPC மற்ற அனைத்தையும் காலாவதியாக்கிவிட்டதா என்று விவாதிப்பதிலேயே தங்கள் முழு மதிய நேரத்தையும் வீணடிக்கிறார்கள். அந்த விவாதம் முக்கியப் புள்ளியைத் தவறவிடுகிறது. நீங்கள் சிறந்த புரோட்டோகாலைத் தேர்ந்தெடுக்கவில்லை. நீங்கள் சரியான எல்லையைத் தேர்ந்தெடுக்கிறீர்கள். உங்கள் Kubernetes கிளஸ்டருக்குள் சிறப்பாகச் செயல்படும் ஒரு புரோட்டோகால், நீங்கள் அதை ஆயிரம் வெளிப்படையான டெவலப்பர்களிடம் ஒப்படைக்கும்போது திணறும். உங்கள் மொபைல் ஆப்பிற்குத் தேவையான அலைவரிசையை (bandwidth) மிச்சப்படுத்தும் ஒன்று, நீங்கள் அதை பொதுவான வினவல்களுக்கு (public queries) திறந்தால் உங்கள் உள்கட்டமைப்பையே திவாலாக்கிவிடும். இந்த முடிவை ஒரு தொழில்நுட்பப் புகழ் போட்டி போலக் கருதினால், உங்கள் குழுவில் உள்ள தற்போதைய உறுப்பினர்கள் அனைவரும் விலகிய பிறகும் நீடிக்கும் ஒரு கட்டமைப்புத் தேய்மானத்தை (architectural debt) நீங்கள் உருவாக்குகிறீர்கள்.
எல்லைக் கொள்கை (The Boundary Principle)
கட்டமைப்பு (Architecture) என்பது சமரசங்களைப் (trade-offs) பற்றியது, வெற்றியாளர்களைப் பற்றியது அல்ல. சரியான கேள்வி "எது வேகமானது?" அல்லது "எது புதியது?" என்பது அல்ல. அது "மறுமுனையில் யார் அமர்ந்திருக்கிறார்கள், அவர்கள் எதைக் கட்டுப்படுத்துகிறார்கள்?" என்பதாகும். புரோட்டோகால்கள் என்பவை எல்லைப் பொருட்கள் (boundary objects). தவறான ஒன்றைத் தேர்ந்தெடுப்பது உங்களைத் தாமதப்படுத்துவது மட்டுமல்ல; அது உங்கள் அமைப்பிற்குள் பல ஆண்டுகாலத் தவறுகளைப் பதிவிறக்கிவிடும்.
பொது API-கள்: REST சலிப்பானது அல்ல, அது பொறுப்பானது
உங்கள் நுகர்வோர் (consumer) நீங்கள் இதுவரை பார்த்திராத ஒரு வெளி டெவலப்பராக இருக்கும்போது, உங்கள் API என்பது வெறும் இடைமுகம் (interface) மட்டுமல்ல, அது ஒரு தயாரிப்பு (product). அந்த டெவலப்பர் அதிகாலை இரண்டு மணி நேரத்தில் curl மற்றும் Postman collection ஆகியவற்றைக் கொண்டு பிழைத்திருத்தம் (debugging) செய்கிறார். அவர் தனது முதல் அழைப்பைச் செய்வதற்கு முன்பே ஒரு தனிப்பயன் கிளையண்ட் லைப்ரரியை (custom client library) நிறுவ வேண்டும் அல்லது ஒரு ஸ்கீமா மொழியைக் (schema language) கற்க வேண்டும் என்றால், நீங்கள் ஏற்கனவே அவரை இழந்துவிட்டீர்கள் என்று அர்த்தம்.
REST இங்கு நிலைத்திருக்கிறது, ஏனெனில் அது இணையத்தின் அடிப்படையானது. HTTP முறைகள் (methods), நிலை குறியீடுகள் (status codes) மற்றும் JSON ஆகியவை பொதுவான மொழிகளாக உள்ளன. கேச்சிங் (Caching) என்பது ஒரு கூடுதல் அம்சம் அல்ல; அது ஏற்கனவே இருக்கும் உள்கட்டமைப்பு. பிரவுசர்கள், CDNs மற்றும் எட்ஜ் கேச்சுகள் (edge caches) Cache-Control தலைப்புகள் மற்றும் ETag சரிபார்ப்பை இயல்பாகவே புரிந்துகொள்கின்றன. நீங்கள் ஒரு சாதாரண CDN-க்கு பின்னால் REST API-ஐ வைத்து, கேச்சிங் லாஜிக் (caching logic) எழுதாமலேயே உடனடி அலைவரிசைச் சேமிப்பைப் பெறலாம். பொதுப் போக்குவரத்து (public traffic) கணிக்க முடியாததாக இருக்கும்போதும், உங்கள் கிளவுடிலிருந்து வெளியேறும் ஒவ்வொரு ஜிகாபைட்க்கும் நீங்கள் பணம் செலுத்த வேண்டியிருக்கும் போதும் இது முக்கியத்துவம் பெறுகிறது.
இதற்கு நேர்மாறாக, GraphQL ஒரு பொது எல்லைக்கு (public boundary) அதிக வரிச் சுமையை (heavy tax) கொண்டுவருகிறது. ஒரு கவனக்குறைவான அல்லது தீய நோக்கமுள்ள வினவல் (query) உங்கள் தரவுத்தளத்தை (database) முடக்குவதைத் தடுக்க, பொது GraphQL எண்ட்பாயிண்டுகளுக்கு (endpoints) வினவல் செலவு பகுப்பாய்வு (query cost analysis), ஆழக் கட்டுப்பாடு (depth limiting) மற்றும் சிக்கல்தன்மை மதிப்பீடு (complexity scoring) ஆகியவை தேவைப்படுகின்றன. நீங்கள் ஒரு API-ஐ மட்டும் வழங்கவில்லை; நீங்கள் ஒரு வினவல் செயலாக்க இயந்திரம் (query execution engine), ஒரு ரேட்-லிமிட்டிங் உத்தி (rate-limiting strategy) மற்றும் ஒரு கம்ப்யூட் பில்லிங் மாடலையும் (compute billing model) உருவாக்குகிறீர்கள். மிகப்பெரிய தளங்களின் செயல்பாட்டுத் திறன் (operational muscle) உங்களிடம் இல்லையென்றால், பொதுவான பயன்பாட்டிற்கு இந்த கூடுதல் சுமை ஆபத்தானது. REST இயல்பாகவே பாதுகாப்பு வேலிகளை (guardrails) அமைக்கிறது. ஒவ்வொரு எண்ட்பாயிண்ட்டும் ஒரு வேலையை மட்டுமே செய்கிறது. நுகர்வோர் நீங்கள் வழங்குவதைத் தவிர வேறு எதையும் கற்பனை செய்து எடுக்க முடியாது.
உள் சேவைகள்: முழுத் தொடர்பையும் கட்டுப்படுத்துங்கள் (Internal Services: Own the Whole Pipe)
உங்கள் நிறுவனத்திற்குள், உரையாடல் மாறுகிறது. கிளையண்ட் மற்றும் சர்வர் ஆகிய இரண்டையும் நீங்கள் கட்டுப்படுத்துகிறீர்கள். அழைப்புச் சங்கிலியில் (call chain) உள்ள ஒவ்வொரு சேவைக்கும் எந்தத் தொழில்நுட்பத் தொகுப்பைப் (technology stack) பயன்படுத்த வேண்டும் என்பதை நீங்கள் தீர்மானிக்கலாம். இங்குதான் gRPC தனது பலத்தை நிரூபிக்கிறது.
முதலில், JSON-ஐப் புனிதமானதாகக் கருதுவதை நிறுத்துங்கள். Protocol Buffers, JSON-ஐ விட சுமார் மூன்று மடங்கு வேகமாகத் தரவை வரிசைப்படுத்துகிறது (serialize). அதன் வடிவம் பைனரி (binary) என்பதால், தரவுப் பொதிகள் (payloads) சிறியதாக இருக்கும். ஒரு பரபரப்பான உள் நெட்வொர்க்கில், அந்த மில்லி விநாடிகளும் மெகாபைட் அளவுகளும் உண்மையான பணமாகவும், குறைந்த லேட்டன்சியாகவும் (lower tail latency) மாறும். மிக முக்கியமாக, Protobuf உங்களுக்கு ஒரு கண்டிப்பான ஒப்பந்தத்தை (strict contract) வழங்குகிறது. நீங்கள் ஒரு புலத்தின் வகையை (field type) மாற்றும்போதோ அல்லது ஒரு செய்தியின் பெயரை மாற்றும்போதோ, அந்தப் பிழை கம்பைல் நேரத்திலேயே (compile time) தெரியவரும்; உற்பத்திச் சூழலில் (production) ஒரு கீழ்நிலைச் சேவை (downstream service) பிழைகளைத் தூக்கத் தொடங்கும் அதிகாலை மூன்று மணி நேரத்தில் வராது.
gRPC, HTTP/2 மூலம் இயங்குகிறது, எனவே உங்களுக்கு ஹெடர் கம்ப்ரஷன் (header compression), மல்டிபிளெக்சிங் ஸ்ட்ரீம்கள் (multiplexed streams) மற்றும் உண்மையான ஸ்ட்ரீமிங் வசதிகள் கிடைக்கின்றன. சேவைகளுக்கு இடையே அதிகத் தரவுப் பரிமாற்ற நிகழ்வுகளை (high-throughput events) அல்லது நிகழ்நேரப் புதுப்பிப்புகளை (real-time updates) அனுப்புகிறீர்கள் என்றால், சர்வர்-சைடு மற்றும் இருவழி ஸ்ட்ரீமிங் (server-side and bidirectional streaming) ஆகியவை இயல்பான அம்சங்களாகும்; அவை ஒரு ரிக்வெஸ்ட்-ரெஸ்பான்ஸ் கட்டமைப்பில் தற்காலிகமாக இணைக்கப்பட்ட (duct-taped) முறைகள் அல்ல.
இதில் ஒரு கடினமான சிக்கல் உள்ளது: gRPC-ஐ நேரடியாக ஒரு பிரவுசருடன் இணைக்காதீர்கள். பிரவுசர் நெட்வொர்க்கிங் மாதிரிகள் gRPC எதிர்பார்க்கும் விதத்தில் HTTP/2-ஐப் பயன்படுத்துவதில்லை. ஒரு பிரவுசர் பேக்எண்டுடன் (backend) பேசுவதற்கு நீங்கள் grpc-web மற்றும் Envoy போன்ற ஒரு ப்ராக்ஸியை (proxy) உங்கள் கட்டமைப்பில் இணைக்க வேண்டியிருக்கும். இது ஒரு பிழை அல்ல; இது ஒரு எல்லைச் சிக்னல் (boundary signal). gRPC-ஐ உங்கள் ஃபயர்வால் (firewall) பின்னால், ஒருவரையொருவர் நம்பும் சேவைகளுக்கு இடையே வைத்திருங்கள், அதன் பிழைத்திருத்தச் சிக்கலை (debugging complexity) வேகத்திற்கான விலையாகக் கருதுங்கள். JSON போல பைனரி தரவுகளை லாக் கோப்புகளில் (log files) எளிதாகப் பார்த்துவிட முடியாது.
சிக்கலான UI-கள் மற்றும் மொபைல்: GraphQL-ன் தனித்துவம் (Complex UIs and Mobile: GraphQL's Niche)
நவீன மொபைல் திரைகள் பல பகுதிகளின் தொகுப்பாக உள்ளன. ஒரு திரைக்குப் பயனர் சுயவிவரம் (user profile) தேவைப்படலாம்,