GraphQL थोड़ा परेशान करता है

• GraphQL बेहतरीन है, लेकिन थोड़ा overhyped लगता है
• लगता है कि शुरुआती~मध्यम स्तर के डेवलपर YouTube देखकर GraphQL इस्तेमाल करने लगते हैं, लेकिन यह सही नहीं लगता
• फायदे
  • जो डेटा चाहिए उसे आसानी से व्यक्त किया जा सकता है
  • bandwidth बचती है. जितना चाहिए उतना एक बार में लाया जा सकता है
  • डेटा consumers के लिए documentation बनाना आसान
  • subscriptions का इस्तेमाल अधिक आसानी से किया जा सकता है
  • API calls को एक साथ bundle करना संभव
• नुकसान
  • वास्तव में इस्तेमाल करना कष्टदायक है. अगर आपके backend के अनुसार आपकी भाषा में generation नहीं होता, तो आपको 2 या उससे अधिक type systems मैनेज करने पड़ते हैं
  • map/table/dictionary का support नहीं है. यह सच में बड़ी बात है. चाहें न चाहें, कहीं न कहीं {[key: string] : T} का इस्तेमाल करना पड़ता है
  • API versioning के लिए कोई स्पष्ट तरीका नहीं है. अंत में आप MyQueryV1.01, MyQueryV1.02, MyQueryV1.03 जैसी चीज़ें करने लगेंगे
• अगर आप Facebook द्वारा GraphQL के लिए सोचे गए solution/problem set को handle नहीं कर रहे हैं, तो GraphQL का इस्तेमाल मत कीजिए
• दूसरे senior developers नए डेवलपर्स को इस दलदल में फँसने से बचाने के लिए क्या समझदारी भरी बातें कह सकते हैं?

HN की टिप्पणियाँ

• GraphQL की सबसे बड़ी समस्या यह है कि DOS attacks से बचाव करने या उन लोगों को रोकने के लिए आपको काम करना पड़ता है जो आपका पूरा DB डाउनलोड करना चाहते हैं
  • ऐसे queries बनाना बहुत आसान है जो आपके सिस्टम पर बेवजह भारी लोड डाल दें
  • क्या-क्या करना पड़ता है, यह देखने के लिए Shopify को देखिए. वे लौटाए जाने वाले डेटा की मात्रा पर rate limit लगाते हैं, cursor और pagination भी संभालते हैं. इंटरनेट पर दिखने वाले सुंदर GraphQL examples के विपरीत, उनका schema बहुत बड़ा और बदसूरत है
• GraphQL बड़ी tech companies की organizational problems सुलझाने का एक शानदार तरीका है
  • जैसे जब API maintain करने वाली टीम और बदलाव माँगने वाली टीम अलग-अलग हों
  • अगर organization बड़ी है, तो ऐसे मामलों में बदलाव के लिए बहुत लंबा इंतज़ार करना पड़ता है, और GraphQL इसकी ज़रूरत कम कर देता है
  • अगर organization छोटी है, तो क्या जो कमी है उसे सीधे खुद बनाकर जोड़ देना बेहतर नहीं होगा?
• चाहे यह जानबूझकर हो या नहीं, GraphQL frontend developers को backend developers की आवश्यकताओं से decouple करके उन्हें तेज़ी से आगे बढ़ने देता है
  • backend developer डेटा model बनाकर उसे GraphQL से expose कर दे, तो frontend developer जिसने उस backend developer से कभी मुलाकात भी न की हो, वह भी तुरंत इसका इस्तेमाल कर सकता है
  • वे तुरंत query की जाने वाली चीज़ें बदल सकते हैं और जो चाहिए वह ले सकते हैं
  • इससे सब लोग तेज़ी से आगे बढ़ पाते हैं
  • लेकिन backend developer होने के नाते, मुझे GraphQL सच में नापसंद है

[bichi]

GraphQL थोड़ा परेशान करता है। बहुत ज़्यादा नहीं, लेकिन थोड़ा तो करता ही है। फिर भी यह टीम के सदस्यों के बीच communication cost को निश्चित रूप से कम कर देता है, इसलिए उस समय में इसके परेशान करने वाले हिस्सों को हल करना ज़्यादा efficient है। और देखने में यह सच में बहुत बदसूरत है। लेकिन फिर भी मैं GraphQL इस्तेमाल करने की सलाह देता हूँ। क्योंकि चलो tRPC इस्तेमाल करें इस बात से शायद ही कोई सहमत होगा। ज़्यादातर लोग किसी तकनीक को ठीक से इस्तेमाल करके देखे बिना ही अनुमान लगाकर उसे अपनाने से मना कर देते हैं, और उसे बदलने के लिए बहुत ताकतवर authority के साथ आगे बढ़ना पड़ता है। 1~2 तकनीकों पर ऐसा किया जा सकता है, लेकिन अगर हर चीज़ को ज़बरदस्ती थोपो तो नुकसान ज़्यादा होता है, इसलिए वह भी नहीं कर सकते... तो आखिरकार जितना ज़्यादा से ज़्यादा लोगों को मनाया जा सकता है, वह स्तर GraphQL ही है, हाय... यह घटिया REST, यही सच में communication cost बहुत बढ़ाने वाली खराब पाषाण युग की तकनीक है, हाय...

[alucard]

GeekNews पढ़ते-पढ़ते मुझे साइन अप करने पर मजबूर करने वाली यह पहली पोस्ट है। मैंने The bad पार्ट पर जवाब दे दिया है.

क्लाइंट/सर्वर, दोनों के नज़रिए से फायदे-नुकसान हो सकते हैं, लेकिन इन्हें साथ रखकर देखें तो GraphQL schema सर्वर और क्लाइंट के बीच गायब abstraction layer को भर देता है — इसकी सबसे बड़ी value proposition को जानते हुए भी यह कहना कि सामान्य product में REST पर विचार करेंगे, मुझे व्यक्तिगत रूप से थोड़ा पुरानी बात जैसा लगता है।
The bad

• It is actually a pain to use, depending on the backend you are using you'll have to manage
  two or more type systems if there are no code first generates in your language
  आख़िर दूसरे शब्दों में कहें तो मतलब यह हुआ कि अगर ठीक से इस्तेमाल करें तो अच्छा है? code generation वगैरह आजकल कोई समस्या भी नहीं है। tooling इतनी आगे बढ़ चुकी है।
• It doesn't support map/tables/dictionaries. This is actually huge. I get that there might be
  some pattern where you don't want to allow this but for the majority of situations working with json api's you'll end up with a {[key: string] : T} somewhere
  यह बात Production Ready में भी कही गई है, लेकिन Type System के फ़ायदों का उपयोग करें तो यह ऐसा हिस्सा नहीं लगता जिस पर बहुत सोचने की ज़रूरत हो। key: string रखने के बजाय सटीक field तय कर दें, बस।
• No clear path for Api versioning you'll end up with MyQueryV1.01 MyQueryV1.02 MyQueryV1.03
  GraphQL मूल रूप से versionless है....
  Don't use Graphql unless you're managing a solution/problem set that facebook intended graphql for Invest your time in a simpler solution then running to GraphQL first
  यह कुछ वैसा ही लगता है जैसे कहना कि अगर आप Facebook द्वारा हल की जाने वाली समस्या नहीं सुलझा रहे, तो React भी मत इस्तेमाल कीजिए।

[bichi]

नमस्ते, आपने बहुत अच्छी बात कही। क्या हम एक-दूसरे के संपर्क में रह सकते हैं? मुझे ऐसे लोगों की ज़रूरत है जो ऐसा ही सोचते हों। दूसरे लोगों (टीम के सदस्यों) को मनाना बहुत मुश्किल है।

[alucard]

हाहा, मैंने कमेंट थोड़ा देर से देखा..!! मैं GraphQL Korea Slack में Alucard नाम का निकनेम इस्तेमाल करता हूँ :)

[sixmen]

मैंने GraphQL को अपेक्षाकृत शुरुआती दौर में अपनाया था, और उस समय इसकी व्याख्या ज़्यादातर backend-केंद्रित होती थी। इसलिए शायद यह धारणा बन गई कि backend में इससे कुछ फ़ायदा होगा।

मैंने तरह-तरह से काफ़ी हाथ-पैर मारने के बाद, जब बाद में कंपनी में आए लोग या इंटरव्यू देने वाले मुझसे पूछते हैं, तो मैं समझाता हूँ कि backend के लिए यह मुश्किल है, लेकिन frontend के लिए अच्छा है. :)

[bbulbum]

#लेकिन एक बैकएंड डेवलपर के तौर पर मुझे GraphQL सच में पसंद नहीं है
सहमत हूँ..

[ifmkl]

मुझे तुरंत यही लगा कि यह चीज़ अपने सही इस्तेमाल की जगह पर ही ठीक बैठती है।

[kbumsik]

चाहे यह इरादतन हो या नहीं, GraphQL फ्रंटएंड डेवलपर्स को बैकएंड डेवलपर्स की आवश्यकताओं से decouple होकर तेज़ी से काम करने देता है

यही GraphQL इस्तेमाल करने की वजह है। GraphQL spec में भी साफ़ लिखा है कि यह फ्रंटएंड के लिए है 1
मैंने भी अपने नए startup में GraphQL इस्तेमाल करना शुरू किया है, और पहले की तुलना में API को लेकर फ्रंटएंड इंजीनियरों के साथ बात करने की ज़रूरत निश्चित रूप से कम हुई है।

GraphQL को वास्तव में इस्तेमाल करने से पहले जिन समस्याओं की मैंने कल्पना भी नहीं की थी, वे बैकएंड इंजीनियर के नज़रिए से थोड़ी तकलीफ़देह ज़रूर हैं, लेकिन REST API design को सही करने के लिए सिर खपाने से यह मुझे कहीं बेहतर लगता है।

[hwasurr]

कोई भी तकनीक परफेक्ट नहीं होती! मेरा मानना है कि अगर किसी तकनीक की कमियों को दूर करने में लगने वाली लागत उठाने लायक उसकी जरूरत हो, या वह कोई और बड़ा समस्या हल करती हो, तो उसे अपनाने पर विचार किया जा सकता है। आखिर तकनीक/टूल की उपयुक्तता हमेशा उपयोगकर्ता की परिस्थिति पर निर्भर करती है।

दूसरी ओर, मुझे यह भी लगता है कि GraphQL की आलोचना होने की एक वजह शायद यह भी है कि उसने खुद को 'आसान' होने वाली इमेज के साथ पेश किया है।

[jjpark78]

शुरुआत में जब GraphQL आया था और POC प्रोजेक्ट पर काम कर रहे थे, तब multipart को ठीक से support करने वाला कोई engine नहीं था, इसलिए काफ़ी दिक्कत हुई थी..

[gjen6s]

मैंने भी पहले से छोटे प्रोजेक्ट्स में GraphQL का इस्तेमाल किया गया देख कर अक्सर सोचा था कि क्या यह बहुत ज़्यादा over-spec नहीं है.. लगता है, सबकी सोच काफ़ी मिलती-जुलती है

[xguru]

शुरुआती टिप्पणियां ही अनुवाद करके देखी हैं। 400 से ज़्यादा टिप्पणियां आई हैं, इसलिए उन सबको पढ़ना भी मुश्किल है।