Drupal एक backend के रूप में: GraphQL, JSON:API, RESTful, और API चयन में छिपी महंगी गलती

एक बार एक CTO ने मुझसे, decoupled Drupal planning meeting के बीच में, पूछा: “तो हमें कौन-सा API इस्तेमाल करना चाहिए?”

कमरे में एक सेकंड के लिए सन्नाटा छा गया। Frontend GraphQL चाहता था। Backend JSON:API चाहता था। एक integration vendor पहले ही REST मान चुका था। Product owner बस चाहता था कि mobile app वेबसाइट releases का इंतज़ार करना बंद कर दे।

यह छोटा-सा सवाल आमतौर पर technical लगता है। लेकिन ऐसा नहीं है। यह governance का सवाल है, budget का सवाल है, और कभी-कभी developer hoodie पहने हुए hiring का सवाल भी होता है।

Drupal decoupled products के लिए एक बहुत सक्षम backend हो सकता है। इसमें पहले से structured content, roles, permissions, workflows, revisions, translations, media handling, taxonomy, और एक mature module ecosystem मौजूद है। मुश्किल हिस्सा यह तय करना है कि वह content Drupal से बाहर कैसे निकलेगा। Core Drupal में native JSON:API support है, GraphQL contributed module के ज़रिए उपलब्ध है, और Drupal का RESTful Web Services module custom resource-style endpoints के लिए अब भी एक विकल्प है। Drupal की अपनी decoupled documentation इस विभाजन को साफ़-साफ़ बताती है: JSON:API core में है, GraphQL contributed है, और Drupal APIs के ज़रिए external frontend को content expose कर सकता है।

फिर भी teams गलत चुनाव करती रहती हैं।

वे GraphQL चुनती हैं क्योंकि वह modern लगता है। वे REST चुनती हैं क्योंकि सभी ने उसे इस्तेमाल किया है। वे JSON:API चुनती हैं क्योंकि वह मौजूद है। इनमें से कोई भी strategy नहीं है।

इसका ज्यादा स्पष्ट version यह है: Drupal-backed content platforms के अधिकांश मामलों में JSON:API default starting point होना चाहिए। GraphQL को earn किया जाना चाहिए। REST को उन मामलों के लिए बचाकर रखना चाहिए जहाँ बाकी दोनों बहुत broad या बहुत opinionated हों।

इससे कुछ लोग नाराज़ होंगे। अच्छा है।

boring winner से शुरुआत करें: JSON:API

JSON:API सबसे अच्छे अर्थ में boring है।

Drupal का core JSON:API module Drupal entities के लिए JSON:API specification implement करता है। यह site content के लिए CRUD operations expose करने का zero-configuration, opinionated तरीका देता है, और Drupal के Entity API, Field API, caching, authentication, और authorization systems से जुड़ा होता है।

इस वाक्य में वह हिस्सा है जिसकी executives को परवाह करनी चाहिए: core module।

Core मायने रखता है। Core का आमतौर पर मतलब होता है कम vendor surprises, आसान maintenance planning, ज्यादा स्पष्ट security posture, और “हमें वही एक contractor चाहिए जो custom API layer समझता है” जैसे जोखिम में कमी। Drupal की JSON:API documentation कहती है कि module entity types और bundles के आसपास APIs expose करता है, filtering, includes, pagination, sorting, revisions, translations, GET, POST, PATCH, DELETE, file uploads, और events के ज़रिए resource customization support करता है।

एक practical example: एक media company की कल्पना करें जिसमें articles, authors, topics, landing-page teasers, और images हैं। Frontend team को Next.js में article pages चाहिए। Mobile app को वही article body, hero image, author name, और related topics चाहिए। JSON:API उन Drupal entities को expose कर सकता है बिना backend team को शुरुआत से API language invent करने के लिए मजबूर किए। Related resources को includes के ज़रिए embed किया जा सकता है, और collections को filter या paginate किया जा सकता है।

क्या payload सुंदर होता है? कभी-कभी। कभी-कभी ऐसा लगता है जैसे किसी committee ने लंबी lunch meeting के बाद उसे design किया हो।

लेकिन यही बात भी महत्वपूर्ण है। JSON:API एक specification है, किसी developer की personal taste नहीं। Official JSON:API site इसे JSON में APIs बनाने की specification के रूप में describe करती है, shared conventions के साथ जो response shape पर बहस कम करते हैं और teams को general tooling इस्तेमाल करने में मदद करते हैं। इसका media type application/vnd.api+json है, और version 1.1 को 30 सितंबर 2022 को finalized किया गया था।

यहाँ एक hidden management benefit है। Standardized response format का मतलब है कि onboarding कम tribal होता है। नया frontend developer अब भी nested data, attributes, और relationships structure को कोस सकता है। ठीक है। कम से कम वह ऐसी चीज़ को कोस रहा है जो documented है।

वह catch जिसके बारे में कोई बात नहीं करना चाहता

JSON:API Drupal के content model को काफी सीधे expose करता है। यह एक strength हो सकती है, खासकर जब Drupal editorial source of truth हो। यह Drupal की internal shape को frontend में बहुत ज्यादा leak भी कर सकता है।

अगर आपका content model clean है, तो JSON:API efficient लगता है। अगर आपका content model पुराने compromises का museum है, तो JSON:API उस mess को visible बना देता है।

मैंने “Article” content types देखे हैं जिनमें field_new_body_2021, field_mobile_summary, field_legacy_related, और field_do_not_use जैसे fields होते हैं। JSON:API इसे magically एक graceful product API में नहीं बदलता। यह वही model expose करता है जो आपके पास वास्तव में है। थोड़ा cruel, शायद। लेकिन useful।

Drupal की documentation एक boundary भी साफ़ करती है: JSON:API entity-oriented CRUD संभालता है, लेकिन login, password reset, और account creation जैसे business rules JSON:API का काम नहीं हैं। अगर आपकी application को “approve vendor”, “calculate renewal quote”, या “submit claim” जैसी domain actions चाहिए, तो सिर्फ इसलिए उन्हें content-entity endpoints में force न करें क्योंकि module convenient है।

वह रास्ता जल्दी ugly हो जाता है।

GraphQL elegant लगता है क्योंकि वह pain को shift करता है

GraphQL आकर्षक है। Frontend ठीक वही fields मांगता है जो उसे चाहिए। Response का shape query जैसा ही होता है। इसमें typed schema होता है। यह component-based frontends के लिए बना हुआ लगता है क्योंकि, सच कहें तो, यह ऐसा ही था। Official GraphQL site GraphQL को APIs के लिए open-source query language और server-side runtime के रूप में describe करती है, strongly typed schema के साथ, और दिखाती है कि client fixed server response पाने के बजाय selected fields मांगता है।

Frontend teams के लिए यह वास्तविक improvement है।

components से बनी homepage लें: hero, featured articles, events, sponsor slots, navigation, regional alerts। REST के साथ frontend कई endpoints call कर सकता है। JSON:API के साथ वह collection request कर सकता है और related resources include कर सकता है, लेकिन structure अब भी entity relationships follow करता है। GraphQL के साथ query screen के करीब दिख सकती है। जब teams product surfaces जल्दी ship करती हैं, तो यह मायने रखता है।

Drupal का GraphQL module developers को Drupal 10 और 11 के लिए GraphQL schema craft और expose करने देता है। यह webonyx/graphql-php के आसपास built है, official GraphQL specification support करता है, /graphql/explorer पर GraphiQL include करता है, और developers को data producer plugins के साथ schema work के लिए custom code देता है।

wording ध्यान से पढ़ें: “craft and expose”।

मौजूदा Drupal GraphQL module कोई magic mirror नहीं है जो हर Drupal field को बस एक neat API में reflect कर दे। Drupal.org कहता है कि पुराना 3.x version Drupal entities से schema automatically generate करता था और API के ज़रिए Drupal details expose करता था, जबकि 4.x schema design developer पर छोड़ता है ताकि Drupal internals छिपाए जा सकें। वही page कहता है कि 4.x में developer को schema setup और map करना होता है।

यह footnote नहीं है। यह invoice है।

GraphQL आपको product और content storage के बीच clean contract दे सकता है। लेकिन किसी को वह contract design करना होगा। किसी को उसे maintain करना होगा जब editors fields जोड़ते हैं, जब design system बदलता है, जब personalization आती है, जब legal regional consent logic मांगता है, जब mobile team को offline sync चाहिए।

असल में, यह बहुत polite है। किसी को इसका owner होना होगा। Ownership कई GraphQL proposals में missing line item है।

कब GraphQL cost के लायक है

GraphQL तब समझ में आता है जब API अपने आप में product हो।

एक बड़ी university जिसके पास दर्जनों microsites, student mobile app, digital signage, faculty profiles, course catalogs, और design system है, GraphQL layer से लाभ उठा सकती है। Consumers varied हैं। Content graph deep है। Frontend teams को selective access चाहिए। Organization ऐसा API contract चाह सकती है जो Drupal bundles की eccentricities छिपा दे।

GraphQL तब भी fit होता है जब Drupal कई sources में से सिर्फ एक हो। शायद content Drupal से आता है, prices ERP से, availability booking engine से, और user entitlements CRM से। GraphQL clients को coherent schema present कर सकता है जबकि resolvers अलग-अलग systems से fetch करते हैं। GraphQL model strongly typed schema और client-specified response shape के आसपास बनाया गया था, और यही वजह है कि यह इस तरह की composition layer में अच्छा काम करता है।

लेकिन एक normal marketing site के लिए headless frontend के साथ? मैं skeptical रहूँगा। थोड़ा annoyed भी।

अगर असली जरूरत है “React को Drupal से articles पढ़ने चाहिए”, तो GraphQL costume party हो सकता है। आप JSON:API includes और filters सीखने से बचने के लिए architecture money खर्च करेंगे। इससे भी बदतर, आप bespoke API layer बना सकते हैं जिसे सिर्फ दो developers समझते हैं।

Drupal GraphQL project page बताता है कि stable releases Drupal की security advisory policy के अंतर्गत covered हैं और Drupal 10 और 11 के लिए recent releases list करता है, जिसमें 29 अप्रैल 2026 को released 8.x-4.14 और Drupal 10.4 और 11 के लिए 5.0.0 beta शामिल हैं। यह healthy है। लेकिन यह design work हटाता नहीं।

Contributed module mature हो सकता है और फिर भी wrong default हो सकता है।

RESTful Web Services: पुराना, उपयोगी, और आमतौर पर overused

REST उन शब्दों में से एक बन गया है जिसका मतलब speaker की जरूरत के अनुसार बदल जाता है। कभी इसका मतलब clean resource-oriented HTTP होता है। कभी इसका मतलब “हम controller से JSON return करते हैं” होता है। कभी इसका मतलब “vendor ने हमें endpoint और PDF दे दिया” होता है।

Roy Fielding की dissertation ने REST को distributed hypermedia systems के लिए architectural style के रूप में introduce किया, जिसमें client-server separation, stateless communication, cache, uniform interface, layered systems, और optional code-on-demand जैसी constraints थीं। वह original idea project plans में REST कहे जाने वाली बहुत-सी चीज़ों से ज्यादा strict है।

Drupal का RESTful Web Services module उपयोगी है क्योंकि यह specific methods, serialization formats, और authentication के साथ resources expose कर सकता है। Drupal study material entities के लिए REST resources, GET, POST, PATCH, और DELETE जैसे methods का support, JSON या XML serialization, और Basic Auth, cookies, या OAuth जैसे दूसरे modules के ज़रिए authentication describe करता है। यह यह भी note करता है कि unsafe methods के लिए X-CSRF-Token request header चाहिए।

इससे REST narrow integration work के लिए अच्छा बनता है।

एक payment provider Drupal को transaction status post करता है। एक warehouse system updated product manuals की list pull करता है। एक partner portal को approved assets के लिए carefully shaped endpoint चाहिए। एक legacy mobile app पहले से /api/v1/articles/{id} expect करता है और इस quarter में rewrite नहीं किया जा सकता।

REST आपको control देता है। यह आपको blank-page syndrome भी देता है।

JSON:API के विपरीत, जहाँ conventions पहले से चुनी गई होती हैं, custom REST endpoint को decisions चाहिए: URL shape, response format, error format, pagination style, filtering syntax, versioning, authentication, cache headers, documentation, deprecation policy। OpenAPI उस surface को document करने में मदद कर सकता है, और OpenAPI Specification HTTP APIs को describe करने का standard, language-agnostic तरीका है ताकि humans और computers source code पढ़े बिना उन्हें समझ सकें।

फिर भी, choices आपको ही करनी पड़ती हैं।

और वे choices टिकती हैं। Week two में design किया गया sloppy endpoint product को वर्षों तक परेशान कर सकता है क्योंकि बाहर मौजूद कोई app version अब भी उस पर depend करता है।

निर्णय यह नहीं है कि “कौन-सा API सबसे अच्छा है?”

यह framing lazy है। माफ़ कीजिए, लेकिन है।

बेहतर सवाल है: आपकी organization किस तरह की coupling afford कर सकती है?

JSON:API consumers को Drupal के entity model से couple करता है। यह अक्सर acceptable होता है जब Drupal main content system हो और frontend replacement presentation layer हो। Reward है speed और कम backend invention।

GraphQL consumers को आपकी team द्वारा design किए गए schema से couple करता है। अच्छी तरह किया जाए, तो वह schema Drupal को hide करता है और product domain express करता है। खराब तरीके से किया जाए, तो वह code में maintained second CMS model बन जाता है।

REST consumers को custom endpoints से couple करता है। Specific integrations के लिए यह excellent है और broad content delivery के लिए dangerous, क्योंकि हर endpoint अपने maintenance tail वाला miniature product बन जाता है।

यह वह version है जिसे मैं executive steering group के सामने रखता।

Tables थोड़ी sterile होती हैं, लेकिन यह वाली meetings बचाती है।

Project managers को क्या देखना चाहिए

API choice project plan को लोगों की स्वीकारोक्ति से ज्यादा बदलती है।

JSON:API के साथ critical path content modeling है। अगर content model thoughtful है, तो API work जल्दी आगे बढ़ सकता है। अगर content model chaotic है, तो frontend development धीमा हो जाता है क्योंकि हर query एक और editorial compromise expose करती है। Frontend team के pages wire करने से पहले field naming, reusable paragraph patterns, media relationships, taxonomy, और permissions पर senior attention लगाएँ।

GraphQL के साथ critical path schema ownership है। Schema कौन design करता है? Breaking changes कौन review करता है? Resolvers कौन लिखता है? Nested queries जो बहुत ज्यादा backend loads trigger करती हैं, जैसे performance problems कौन handle करता है? Drupal GraphQL module tools और extension points देता है, जिसमें data producer plugins और GraphiQL शामिल हैं, लेकिन यह backend engineering discipline की जरूरत खत्म नहीं करता।

REST के साथ critical path contract discipline है। हर endpoint को documentation, tests, authentication rules, error semantics, और versioning story चाहिए। REST तब cheap लगता है जब पहला endpoint बनता है। पाँचवाँ endpoint सच बताता है।

एक और बात। Authentication को अक्सर underestimate किया जाता है। Drupal JSON:API Drupal के authentication और authorization systems से जुड़ा है, और REST Basic Auth तथा cookies जैसे authentication providers इस्तेमाल कर सकता है, OAuth आमतौर पर contributed modules के ज़रिए जोड़ा जाता है। Lupus Decoupled Drupal documentation Simple OAuth को decoupled setups में token द्वारा API requests authenticate करने के तरीके के रूप में point करती है।

इसे launch से पहले वाले sprint के लिए मत छोड़िए। वह sprint पहले से cursed होता है।

Performance: वह argument जिसे हर कोई simplify करता है

GraphQL fans कहते हैं कि यह over-fetching से बचाता है। सही। JSON:API fans कहते हैं कि includes round trips घटाते हैं। यह भी सही। REST fans कहते हैं कि HTTP caching straightforward है। फिर सही।

अब unpleasant हिस्सा: तीनों fast हो सकते हैं, और तीनों slow हो सकते हैं।

GraphQL payload size घटा सकता है, लेकिन complex nested queries backend को punish कर सकती हैं अगर resolvers careless हों। JSON:API Drupal की response caching और includes इस्तेमाल कर सकता है, लेकिन payloads verbose हो सकते हैं। REST HTTP caching पर neatly map हो सकता है, लेकिन custom endpoints अक्सर performance testing शुरू होने तक cacheability भूल जाते हैं। Fielding की REST constraints में cache शामिल है क्योंकि cache network traffic और latency घटा सकता है, लेकिन stale data और cache invalidation वास्तविक trade-offs बने रहते हैं। Drupal की JSON:API documentation module को Drupal response caching से explicitly जोड़ती है, जबकि GraphQL module Drupal.org पर Decoupled, Developer tools, और Performance के अंतर्गत categorized है।

इसलिए नहीं, GraphQL automatically “performance option” नहीं है।

पहला performance win आमतौर पर बेहतर content modeling होता है। दूसरा cache strategy। तीसरा silly client behavior से बचना, जैसे same endpoint को बारह बार call करना क्योंकि किसी ने data access layer नहीं लिखा।

Glamorous? नहीं। Effective? हाँ।

एक blunt selection framework

अगर मैं किसी founder या CTO को सलाह दे रहा होता, तो मैं इस sequence से शुरुआत करता।

पहला, Drupal के normal rendered pages इस्तेमाल करें जब तक आपके पास decouple करने का कारण न हो। Decoupling hosting, preview, routing, cache, deployment, authentication, और debugging complexity जोड़ता है। Drupal की अपनी decoupled documentation standard Drupal और decoupled Drupal को अलग करती है यह बताते हुए कि layout frontend में चला जाता है और backend APIs के ज़रिए content expose करता है। यह shift free नहीं है।

दूसरा, अगर आप मुख्य रूप से modern frontend के लिए decoupling कर रहे हैं, तो JSON:API से शुरू करें। एक real page बनाएँ, demo नहीं। Media, menus या navigation, related content, preview needs, required होने पर authentication, और cache behavior शामिल करें। आप छह architecture diagrams से ज्यादा एक ugly page से सीखेंगे।

तीसरा, GraphQL पर तभी जाएँ जब consumer experience schema work को justify करे। अच्छे reasons में multiple frontend consumers, Drupal internals छिपाने की जरूरत, complex content graphs, या systems के बीच aggregation शामिल हैं। खराब reasons में “हमारे frontend developer को Apollo पसंद है” और “investor deck में GraphQL लिखा है” शामिल हैं।

चौथा, REST उन integrations के लिए इस्तेमाल करें जिन्हें tight boundaries चाहिए। Partner export के लिए custom endpoint clean हो सकता है। Hand-rolled endpoints से बना पूरा content platform बिना labels वाली keys से भरी drawer बन सकता है।

और Drupal model साफ़ करें। कृपया। कोई API layer उस content model को पूरी तरह rescue नहीं कर सकता जिसका owner कोई नहीं है।

“future-proof” की politics

Executives को “future-proof” phrase पसंद है। मैं समझता हूँ क्यों। कोई भी backend rebuild approve करके अठारह महीने बाद यह नहीं सुनना चाहता कि चुने गए API ने company को corner में paint कर दिया।

लेकिन future-proofing आमतौर पर fanciest API चुनने से कम और यह चुनने से ज्यादा जुड़ी होती है कि change कहाँ allowed है।

JSON:API कहता है: “Drupal का model ही contract है।” यह honest और fast है।

GraphQL कहता है: “हमारा product schema ही contract है।” यह powerful और expensive है।

REST कहता है: “यह endpoint ही contract है।” यह precise है और आसानी से maintenance problem में multiply हो सकता है।

कोई universal winner नहीं है। सिर्फ fit है।

मेरा bias simple है: उस least custom चीज़ से शुरू करें जो product को support कर सके। Drupal में इसका मतलब आमतौर पर JSON:API होता है। GraphQL तब जोड़ें जब आप owner और budget का नाम बता सकें। REST तब जोड़ें जब integration इतनी specific हो कि उसे अपना doorway deserve हो।

सबसे खराब choice वह है जो fashion के लिए की जाती है, क्योंकि fashion maintenance के लिए कभी नहीं आता।

क्या आप market की #1 Drupal development company ढूँढ रहे हैं? आपने अभी उसे पा लिया है।

हम सबसे अच्छी Drupal-focused digital agency हैं, जो तेज़, secure और scalable platforms deliver करने के लिए बनी है — बिना compromise के। New builds और redesigns से लेकर migrations और long-term support तक, हमारे Drupal experts boutique-level attention के साथ enterprise-grade results deliver करते हैं।

आज ही एक call book करें और आइए आपके Drupal roadmap को high-performing reality में बदलें।