6 साल बाद मैंने GraphQL छोड़ क्यों दिया

• 2018 से 6 साल तक इस्तेमाल करने के बाद, मैं सच में GraphQL का बड़ा प्रशंसक था, लेकिन अब संदेह होने लगा है
• अब मैं GraphQL की सिफारिश क्यों नहीं करता और मेरे हिसाब से बेहतर विकल्प क्या हैं, यह बताना चाहता हूँ

attack surface

• GraphQL query language को expose करता है, जिससे attack surface बढ़ने का जोखिम होता है।
• authorization से जुड़ी समस्याएँ खास तौर पर महत्वपूर्ण हैं।
  • हर field के लिए उचित permission check की ज़रूरत होती है।
  • REST API में endpoint के हिसाब से authorization check करना ज़्यादा सरल है।

authorization

• हर field के लिए user permission की जाँच करनी पड़ती है।
• REST API में endpoint के हिसाब से authorization check करना ज़्यादा सरल है।

rate limiting

• GraphQL queries पर size limit नहीं होती, इसलिए वे server पर बड़ा load डाल सकती हैं।
• query complexity का अनुमान लगाकर, एक निश्चित complexity से ऊपर की queries को सीमित करने का तरीका है।
• REST API में request count को limit करना ज़्यादा सरल है।

query parsing

• गलत query string server की memory का अत्यधिक उपयोग करा सकती है।
• maximum error count सेट करके parsing रोकने का तरीका है।

performance

data fetching और N+1 समस्या

• field resolver बाहरी data source को कई बार call कर सकते हैं।
• Dataloader pattern का उपयोग करके इस समस्या को हल किया जा सकता है।
• REST में controller पर N+1 समस्या को हल करना ज़्यादा सरल है।

authorization और N+1 समस्या

• authorization code, N+1 समस्या पैदा कर सकता है।
• REST में यह समस्या नहीं होती।

coupling

• GraphQL codebase में business logic, transport layer के साथ बहुत मज़बूती से जुड़ जाता है।
• integration testing की ज़रूरत पड़ती है, और debugging कठिन हो जाती है।

complexity

• GraphQL की security और performance समस्याओं को हल करने के लिए अलग-अलग तरीके codebase की complexity बढ़ा देते हैं।
• REST solutions आम तौर पर अधिक सरल होते हैं।

alternatives

• OpenAPI 3.0+ का उपयोग करने वाली JSON REST API की सिफारिश की गई है।
• अगर static typed language में लिखे गए clients हैं, तो OpenAPI बेहतर विकल्प हो सकता है।
• OpenAPI अपने आप type-safe client code generate कर सकता है।

GN⁺ की राय

• GraphQL शक्तिशाली है, लेकिन security और performance समस्याओं को हल करने में बहुत मेहनत लगती है।
• REST API अपेक्षाकृत सरल है, और कई मामलों में अधिक उपयुक्त हो सकती है।
• OpenAPI type safety और automated tools देकर development productivity बढ़ा सकता है।
• GraphQL अपनाते समय security और performance समस्याओं पर पर्याप्त विचार करना चाहिए।
• REST और GraphQL के फायदे-नुकसान की तुलना करके प्रोजेक्ट के लिए उपयुक्त तकनीक चुनना महत्वपूर्ण है।

[savvykang]

6 साल बाद GraphQL छोड़ने की वजह

GraphQL थोड़ा परेशान करने वाला है (2022)

[yangeok]

RPC की बड़ी लहर का दौर आ रहा है

[ahwjdekf]

वही तो... सिर्फ इसलिए कि कुछ fancy आ गया है, उसे तुरंत लपककर सिर-आंखों पर नहीं बिठा लेना चाहिए.. अब ORM की बारी है। तुम्हारी भी ज़्यादा दूर नहीं है...

[rockmkd]

ORM को आए 20 साल से ज़्यादा हो चुके हैं...

[cometkim]

2018 तक आते-आते PQ इतना नया भी नहीं था (असल में GraphQL पहली बार घोषित होने के समय से ही इसकी सिफारिश की जाती थी), इसलिए यह हैरानी की बात है कि 6 साल तक इसे आज़माने की कोशिश ही नहीं की गई...

[surfindia]

ऊपर बताए गए सभी कारणों की वजह से GraphQL को पूरी तरह खुद implement करना complexity और stability के लिहाज़ से मुश्किल है। मुझे लगता है कि DB के ऊपर hasura या postgraphile जैसी layer रखकर, ज़रूरत के अनुसार इस layer में GraphQL हो या REST, उसे जोड़ने के तरीके से development करना बेहतर होगा।

[GN⁺]

Hacker News की राय

• GraphQL अपनाने के बाद कई समस्याएँ झेलनी पड़ीं। permission management और performance issues की वजह से अब इसे और इस्तेमाल नहीं करना चाहते। सिर्फ frontend में इस्तेमाल करना ठीक हो सकता है, लेकिन backend के साथ इसका integration जटिल है.
• पहले REST सीखा और फिर gRPC इस्तेमाल किया, तो type-safe API काफ़ी आकर्षक लगा। GraphQL के बहुत ज़्यादा फ़ायदे नहीं हैं, और यह तभी उपयोगी लगता है जब यह database की तरह काम करे.
• दो GraphQL प्रोजेक्ट्स पर काम किया; शुरुआत में वे छोटे थे, लेकिन समय के साथ जटिल हो गए। debugging मुश्किल थी और performance problems आईं। REST और RPC ज़्यादा सरल हैं और manage करना आसान है.
• Hasura के संस्थापक के रूप में GraphQL के उपयोग का विकास देखा। data layer के बिना GraphQL बनाना बहुत कठिन है। REST के ऊपर GraphQL इस्तेमाल करना अप्रभावी है। GraphQL का मुख्य use case तब है जब कई data consumers हों.
• frontend engineers queries को central library में store करके reuse करते हैं, जो असल में GraphQL को REST की तरह इस्तेमाल करना है.
• OpenAPI, GraphQL, JSON/HTTP, gRPC इस्तेमाल करने के अनुभव से, GraphQL queries को सीमित करना performance और security issues को कम कर सकता है। Buf Connect ज़्यादातर projects के लिए सबसे उपयुक्त समझौता है.
• Facebook में GraphQL इस्तेमाल करने के अनुभव से पता चला कि बहुत से लोगों के पास वह समस्या ही नहीं है जिसे GraphQL हल करना चाहता है। Facebook versioning और complex object models को संभालने के लिए GraphQL इस्तेमाल करता है.
• Facebook में GraphQL के अच्छी तरह काम करने की वजह यह है कि सभी users logged in होते हैं, और security हर field में अंतर्निहित होती है। अगर SPA और login requirement हो, तो GraphQL उपयोगी हो सकता है.
• GraphQL इस्तेमाल करके देखा तो शुरुआत में अच्छा लगा, लेकिन अंत में बहुत extra work और duplication की ज़रूरत पड़ी। JSON-RPC type endpoints से शुरुआत करना और ज़रूरत के हिसाब से features जोड़ना बेहतर होता.
• छोटे project में GraphQL इस्तेमाल किया तो लगभग हर हिस्सा अच्छा लगा। Apollo Client और graphql-codegen का इस्तेमाल करके Vue 3 के लिए types और functions generate किए। कुछ समस्याएँ थीं, लेकिन इसने type level पर कई errors पकड़ लिए.