पाठ 25 / 25
GraphQL और gRPC
REST, GraphQL और gRPC की तुलना करें और जानें कि public APIs, rich UIs या internal services के लिए कौन-सा style फिट है।
GraphQL: एक एंडपॉइंट, सटीक फ़ील्ड
GraphQL एक ही एंडपॉइंट उजागर करता है जहाँ क्लाइंट एक ही क्वेरी में संबंधित रिसोर्स में बिल्कुल वे फ़ील्ड बताता है जो उसे चाहिए — यह REST की ओवर-फ़ेचिंग (अनुपयोगी फ़ील्ड) और अंडर-फ़ेचिंग (कई राउंड-ट्रिप चाहिए) को ठीक करता है, कीमत पर एक अधिक जटिल सर्वर और कैशिंग की कहानी।
gRPC: बाइनरी, टाइप्ड, तेज़
gRPC JSON टेक्स्ट के बजाय कॉम्पैक्ट बाइनरी Protocol Buffers का उपयोग करते हुए HTTP/2 पर टाइप्ड फ़ंक्शन कॉल करता है — (डी)सिरियलाइज़ करने में बहुत तेज़, सख़्त स्कीमा और स्ट्रीमिंग बिल्ट-इन के साथ। यह REST से कम ब्राउज़र-अनुकूल और कम इंसानी-पठनीय है।
हर एक को कब चुनें
REST: पब्लिक API, सरल रिसोर्स, व्यापक टूलिंग और कैशिंग सपोर्ट। GraphQL: समृद्ध UI (मोबाइल/वेब) जो हर स्क्रीन की अलग ज़रूरत के साथ कई स्रोतों से नेस्टेड डेटा खींचते हैं। gRPC: आपके अपने इंफ़्रास्ट्रक्चर के अंदर सेवा-से-सेवा कॉल जहाँ गति और सख़्त कॉन्ट्रैक्ट ब्राउज़र एक्सेस से ज़्यादा मायने रखते हैं।
त्वरित जाँच: एक मोबाइल ऐप स्क्रीन को एक राउंड-ट्रिप में यूज़र की प्रोफ़ाइल, उनके अंतिम 3 ऑर्डर और अनरीड नोटिफ़िकेशन गिनती चाहिए, कम से कम अतिरिक्त डेटा के साथ। सबसे उपयुक्त क्या है?
- बिल्कुल उन्हीं फ़ील्ड को नाम देने वाली एक GraphQL क्वेरी
- तीन अलग REST कॉल
- एक gRPC स्ट्रीमिंग कॉल
- SOAP service को poll करना
Answer
बिल्कुल उन्हीं फ़ील्ड को नाम देने वाली एक GraphQL क्वेरी — GraphQL बिल्कुल इसी के लिए बना है: एक क्वेरी जो कई रिसोर्स में ठीक ज़रूरी फ़ील्ड खींचती है, न अतिरिक्त राउंड-ट्रिप न अनुपयोगी डेटा।
अंतिम क्विज़ 1/8
अंतिम क्विज़
त्वरित जाँच: कौन-सा HTTP method resource को पूरी तरह बदलता है और idempotent है?
- POST
- PATCH
- PUT
- GET
Answer
PUT — PUT दिए गए body से resource बदल देता है, इसलिए दोहराने पर वही नतीजा मिलता है।
अंतिम क्विज़ 2/8
अंतिम क्विज़
त्वरित जाँच: Resource बनाने वाले सफल POST के लिए कौन-सा status code सही है?
- 200 OK
- 204 No Content
- 302 Found
- 201 Created
Answer
201 Created — 201 निर्माण दर्शाता है और आमतौर पर Location header साथ होता है।
अंतिम क्विज़ 3/8
अंतिम क्विज़
त्वरित जाँच: बड़े बदलते datasets के लिए cursor pagination क्यों बेहतर है?
- It stays fast and stable under inserts
- It lets you jump to page 10
- It needs no limit
- It avoids sorting
Answer
It stays fast and stable under inserts — Cursors धीमे OFFSET scans और खिसकते pages से बचाते हैं।
अंतिम क्विज़ 4/8
अंतिम क्विज़
त्वरित जाँच: कौन-सा बदलाव breaking है और नए API version की जरूरत है?
- Adding an optional field
- Renaming a response field
- Adding a new endpoint
- Improving docs
Answer
Renaming a response field — पुराना field name पढ़ने वाले clients fail हो जाएँगे।
अंतिम क्विज़ 5/8
अंतिम क्विज़
त्वरित जाँच: JWT access token को छोटी अवधि का क्यों रखें?
- Because it is large
- Because it needs a database
- Because it cannot be easily revoked
- Because it is encrypted
Answer
Because it cannot be easily revoked — छोटी अवधि token leak होने पर नुकसान सीमित करती है; refresh tokens उसे नवीनीकृत करते हैं।
अंतिम क्विज़ 6/8
अंतिम क्विज़
त्वरित जाँच: Rate limit पार करने पर API को क्या लौटाना चाहिए?
- 403 Forbidden
- 200 OK
- 404 Not Found
- 429 Too Many Requests
Answer
429 Too Many Requests — 429 और Retry-After clients को पीछे हटने में मदद करता है।
अंतिम क्विज़ 7/8
अंतिम क्विज़
त्वरित जाँच: Idempotency-Key header किससे बचाता है?
- Duplicate processing of retried requests
- Slow queries
- Cross-site scripting
- Large payloads
Answer
Duplicate processing of retried requests — वही key दोबारा आने पर server पहला नतीजा दोहरा देता है।
अंतिम क्विज़ 8/8
अंतिम क्विज़
त्वरित जाँच: If-None-Match के साथ ETag मेल खाने पर क्या लौटता है?
- 200 with the full body
- 304 Not Modified with no body
- 404 Not Found
- 409 Conflict
Answer
304 Not Modified with no body — Freshness की पुष्टि होते हुए body network पर नहीं जाता।