Drupal kao backend: GraphQL, JSON:API, RESTful i skupa greška koja se krije u izboru API-ja

Jednom me je CTO pitao, usred sastanka za planiranje decoupled Drupal rešenja: „Dakle, koji API bi trebalo da koristimo?”

Na trenutak je u prostoriji zavladala tišina. Frontend je želeo GraphQL. Backend je želeo JSON:API. Jedan integracioni vendor je već pretpostavio REST. Product owner je samo želeo da mobilna aplikacija prestane da čeka release-ove veb-sajta.

To malo pitanje obično zvuči tehnički. Nije. To je pitanje upravljanja, pitanje budžeta, a ponekad i pitanje zapošljavanja obučeno u developerski duks.

Drupal može biti veoma sposoban backend za decoupled proizvode. Već ima strukturiran sadržaj, uloge, dozvole, workflow-e, revizije, prevode, upravljanje medijima, taksonomiju i zreo ekosistem modula. Nezgodan deo je odlučiti kako taj sadržaj izlazi iz Drupala. Drupal core ima nativnu podršku za JSON:API, GraphQL je dostupan kroz contributed modul, a Drupalov RESTful Web Services modul ostaje opcija za prilagođene resource-style endpoint-e. Drupalova sopstvena dokumentacija za decoupled pristup jasno navodi podelu: JSON:API je u core-u, GraphQL je contributed, a Drupal može da izloži sadržaj eksternom frontend-u kroz API-je.

Pa ipak, timovi i dalje loše biraju.

Biraju GraphQL zato što zvuči moderno. Biraju REST zato što su ga svi koristili. Biraju JSON:API zato što je tu. Ništa od toga nije strategija.

Evo oštrije verzije: za većinu content platformi zasnovanih na Drupalu, JSON:API bi trebalo da bude podrazumevana početna tačka. GraphQL treba zaslužiti. REST treba rezervisati za slučajeve u kojima su druga dva preširoka ili previše opinionated.

To će neke ljude iznervirati. Dobro.

Počnite sa dosadnim pobednikom: JSON:API

JSON:API je dosadan na najbolji mogući način.

Drupalov core JSON:API modul implementira JSON:API specifikaciju za Drupal entitete. On daje zero-configuration, opinionated način za izlaganje CRUD operacija nad sadržajem sajta i povezan je sa Drupalovim Entity API, Field API, caching, authentication i authorization sistemima.

Ta rečenica sadrži deo do kojeg bi direktorima trebalo da bude stalo: core modul.

Core je važan. Core obično znači manje iznenađenja od vendora, lakše planiranje održavanja, jasniji bezbednosni položaj i manji rizik tipa „treba nam onaj jedan contractor koji razume prilagođeni API sloj”. Drupalova JSON:API dokumentacija kaže da modul izlaže API-je oko tipova entiteta i bundle-ova, podržava filtriranje, includes, paginaciju, sortiranje, revizije, prevode, GET, POST, PATCH, DELETE, upload fajlova i prilagođavanje resursa kroz event-e.

Praktičan primer: zamislite medijsku kompaniju sa člancima, autorima, temama, teaser-ima za landing stranice i slikama. Frontend timu su potrebne stranice članaka u Next.js-u. Mobilnoj aplikaciji je potreban isti body članka, hero slika, ime autora i povezane teme. JSON:API može da izloži te Drupal entitete bez toga da backend tim izmišlja API jezik od nule. Povezani resursi mogu se ugraditi kroz includes, a kolekcije se mogu filtrirati ili paginirati.

Da li je payload lep? Ponekad. Ponekad izgleda kao da ga je komitet dizajnirao posle dugog ručka.

Ali to je takođe poenta. JSON:API je specifikacija, a ne lični ukus developera. Zvanični JSON:API sajt opisuje ga kao specifikaciju za izgradnju API-ja u JSON-u, sa zajedničkim konvencijama koje smanjuju rasprave o obliku odgovora i pomažu timovima da koriste opšte alate. Njegov media type je application/vnd.api+json, a verzija 1.1 finalizovana je 30. septembra 2022.

Ovde postoji skrivena menadžerska korist. Standardizovan format odgovora znači da onboarding manje zavisi od tribal knowledge-a. Novi frontend developer možda će i dalje psovati ugnježdenu strukturu data, attributes i relationships. U redu. Bar psuje nešto što je dokumentovano.

Kvaka koju niko ne želi da pomene

JSON:API prilično direktno izlaže Drupalov model sadržaja. To može biti prednost, posebno kada je Drupal editorial source of truth. Takođe može previše da propusti unutrašnji oblik Drupala u frontend.

Ako je vaš model sadržaja čist, JSON:API deluje efikasno. Ako je vaš model sadržaja muzej starih kompromisa, JSON:API čini nered vidljivim.

Video sam “Article” tipove sadržaja sa poljima kao što su field_new_body_2021, field_mobile_summary, field_legacy_related i field_do_not_use. JSON:API to magično ne pretvara u elegantan product API. On izlaže model koji zaista imate. Možda malo surovo. Ali korisno.

Drupalova dokumentacija takođe jasno postavlja granicu: JSON:API obrađuje entity-oriented CRUD, ali poslovna pravila kao što su login, resetovanje lozinke i kreiranje naloga nisu posao JSON:API-ja. Ako vašoj aplikaciji trebaju domenske akcije kao što su „odobri vendora”, „izračunaj ponudu za obnovu” ili „pošalji zahtev”, nemojte ih gurati u content-entity endpoint-e samo zato što je modul zgodan.

Taj put brzo postaje ružan.

GraphQL deluje elegantno zato što pomera bol

GraphQL je zavodljiv. Frontend traži tačno ona polja koja želi. Odgovor ima isti oblik kao upit. Ima tipiziranu šemu. Deluje kao da je dizajniran za frontend-e zasnovane na komponentama zato što, iskreno, jeste. Zvanični GraphQL sajt opisuje GraphQL kao open-source query language i server-side runtime za API-je sa strongly typed šemom, i pokazuje kako klijent traži izabrana polja umesto da prima fiksni serverski odgovor.

Za frontend timove, to je stvarno poboljšanje.

Uzmite homepage sastavljen od komponenti: hero, istaknuti članci, događaji, sponzorski slotovi, navigacija, regionalna upozorenja. Sa REST-om, frontend može pozivati nekoliko endpoint-a. Sa JSON:API-jem, može tražiti kolekciju i uključiti povezane resurse, ali struktura i dalje prati odnose entiteta. Sa GraphQL-om, upit može izgledati bliže ekranu. To je važno kada timovi brzo isporučuju product surfaces.

Drupalov GraphQL modul omogućava developerima da naprave i izlože GraphQL šemu za Drupal 10 i 11. Izgrađen je oko webonyx/graphql-php, podržava zvaničnu GraphQL specifikaciju, uključuje GraphiQL na /graphql/explorer i developerima daje data producer plugin-e plus prilagođeni kod za rad na šemi.

Pažljivo pročitajte formulaciju: „naprave i izlože”.

Trenutni Drupal GraphQL modul nije magično ogledalo koje jednostavno reflektuje svako Drupal polje u uredan API. Drupal.org kaže da je starija 3.x verzija automatski generisala šemu iz Drupal entiteta i izlagala Drupal detalje kroz API, dok 4.x prepušta dizajn šeme developeru kako bi se Drupal interne stvari mogle sakriti. Ista stranica kaže da 4.x zahteva od developera da postavi i mapira šemu.

To nije fusnota. To je račun.

GraphQL može da vam da čist ugovor između proizvoda i skladišta sadržaja. Ali neko mora da dizajnira taj ugovor. Neko mora da ga održava kada urednici dodaju polja, kada se design system promeni, kada stigne personalizacija, kada pravni tim traži regionalnu consent logiku, kada mobilnom timu treba offline sync.

Zapravo, to je previše učtivo. Neko mora da ga poseduje. Ownership je stavka koja nedostaje u mnogim GraphQL predlozima.

Kada GraphQL vredi troška

GraphQL ima smisla kada je API proizvod sam po sebi.

Veliki univerzitet sa desetinama microsite-ova, studentskom mobilnom aplikacijom, digital signage-om, profilima nastavnika, katalozima kurseva i design system-om može imati koristi od GraphQL sloja. Potrošači su različiti. Content graph je dubok. Frontend timovima je potreban selektivan pristup. Organizacija možda želi API ugovor koji skriva ekscentričnosti Drupal bundle-ova.

GraphQL takođe odgovara kada je Drupal samo jedan izvor među nekoliko. Možda sadržaj dolazi iz Drupala, cene iz ERP-a, dostupnost iz booking engine-a, a korisnička prava iz CRM-a. GraphQL može klijentima predstaviti koherentnu šemu dok resolvers dohvatаju podatke iz različitih sistema. GraphQL model je izgrađen oko strongly typed šeme i response shape-a koji određuje klijent, što je upravo razlog zašto dobro funkcioniše u ovoj vrsti composition layer-a.

Ali za običan marketinški sajt sa headless frontend-om? Bio bih skeptičan. Čak pomalo iznerviran.

Ako je stvarna potreba „React treba da čita članke iz Drupala”, GraphQL može biti maskenbal. Potrošićete arhitektonski novac da izbegnete učenje JSON:API includes i filters. Još gore, možete napraviti bespoke API layer koji razumeju samo dva developera.

Stranica Drupal GraphQL projekta navodi da su stabilna izdanja pokrivena Drupalovom security advisory politikom i prikazuje nedavna izdanja za Drupal 10 i 11, uključujući 8.x-4.14 objavljen 29. aprila 2026. i 5.0.0 beta za Drupal 10.4 i 11. To je zdravo. Ne uklanja dizajnerski rad.

Contributed modul može biti zreo i i dalje biti pogrešan default.

RESTful Web Services: star, koristan i obično prekomerno korišćen

REST je postao jedna od onih reči koje znače šta god govorniku treba da znače. Ponekad znači čist resource-oriented HTTP. Ponekad znači „vraćamo JSON iz controller-a”. Ponekad znači „vendor nam je dao endpoint i PDF”.

Disertacija Roya Fieldinga predstavila je REST kao arhitektonski stil za distribuirane hypermedia sisteme, sa ograničenjima kao što su client-server razdvajanje, stateless komunikacija, cache, uniform interface, layered systems i opcioni code-on-demand. Ta originalna ideja je stroža od velikog dela onoga što se u projektnim planovima naziva REST.

Drupalov RESTful Web Services modul je koristan jer može da izloži resurse sa specifičnim metodama, formatima serijalizacije i autentifikacijom. Drupal studijski materijal opisuje REST resurse za entitete, podršku za metode kao što su GET, POST, PATCH i DELETE, JSON ili XML serijalizaciju i autentifikaciju kroz Basic Auth, cookies ili druge module kao što je OAuth. Takođe napominje da unsafe metode zahtevaju X-CSRF-Token request header.

To čini REST dobrim za usko integraciono delo.

Payment provider šalje status transakcije u Drupal. Warehouse system povlači listu ažuriranih product manual-a. Partner portal treba jedan pažljivo oblikovan endpoint za odobrene assets. Legacy mobilna aplikacija već očekuje /api/v1/articles/{id} i ne može biti prepisana ovog kvartala.

REST vam daje kontrolu. Takođe vam daje sindrom prazne stranice.

Za razliku od JSON:API-ja, gde su konvencije već izabrane, prilagođeni REST endpoint zahteva odluke: oblik URL-a, format odgovora, format greške, stil paginacije, sintaksu filtriranja, versioning, autentifikaciju, cache header-e, dokumentaciju, deprecation policy. OpenAPI može pomoći da se ta površina dokumentuje, a OpenAPI Specification je standardan, jezički nezavisan način opisivanja HTTP API-ja tako da ih ljudi i računari mogu razumeti bez čitanja izvornog koda.

Ipak, morate doneti odluke.

A te odluke ostaju. Nemaran endpoint dizajniran u drugoj nedelji može godinama proganjati proizvod jer neka verzija aplikacije u upotrebi i dalje zavisi od njega.

Odluka nije „koji API je najbolji?”

Takav okvir je lenj. Izvinite, ali jeste.

Bolje pitanje je: kakav tip coupling-a vaša organizacija može da priušti?

JSON:API vezuje potrošače za Drupalov model entiteta. To je često prihvatljivo kada je Drupal glavni content system, a frontend je zamenska presentation layer. Nagrada je brzina i manje backend izmišljanja.

GraphQL vezuje potrošače za šemu koju je dizajnirao vaš tim. Ako je urađeno dobro, ta šema skriva Drupal i izražava product domain. Ako je urađeno loše, postaje drugi CMS model održavan u kodu.

REST vezuje potrošače za prilagođene endpoint-e. To je odlično za specifične integracije i opasno za široku isporuku sadržaja, jer svaki endpoint postaje minijaturni proizvod sa sopstvenim repom održavanja.

Evo verzije koju bih stavio pred executive steering group.

Tabele su pomalo sterilne, ali ova štedi sastanke.

Na šta project manager-i treba da obrate pažnju

Izbor API-ja menja projektni plan više nego što ljudi priznaju.

Sa JSON:API-jem, kritični put je modelovanje sadržaja. Ako je model sadržaja promišljen, API posao može brzo da napreduje. Ako je model sadržaja haotičan, frontend razvoj usporava jer svaki upit otkriva još jedan urednički kompromis. Usmerite senior pažnju na imenovanje polja, reusable paragraph patterns, media relationships, taksonomiju i dozvole pre nego što frontend tim počne da povezuje stranice.

Sa GraphQL-om, kritični put je ownership šeme. Ko dizajnira šemu? Ko pregleda breaking changes? Ko piše resolvers? Ko rešava performance probleme kao što su ugnježdeni upiti koji pokreću previše backend load-ova? Drupal GraphQL modul daje alate i extension points, uključujući data producer plugin-e i GraphiQL, ali ne uklanja potrebu za backend engineering disciplinom.

Sa REST-om, kritični put je disciplina ugovora. Svaki endpoint treba dokumentaciju, testove, pravila autentifikacije, semantiku grešaka i priču o versioning-u. REST izgleda jeftino kada se napravi prvi endpoint. Peti endpoint govori istinu.

Još jedna stvar. Autentifikacija se često potcenjuje. Drupal JSON:API je povezan sa Drupalovim authentication i authorization sistemima, a REST može koristiti authentication provider-e kao što su Basic Auth i cookies, dok se OAuth često dodaje kroz contributed module. Lupus Decoupled Drupal dokumentacija upućuje na Simple OAuth kao način autentifikacije API zahteva tokenom u decoupled setup-ima.

Ne ostavljajte to za sprint pre lansiranja. Taj sprint je već proklet.

Performanse: argument koji svi pojednostavljuju

GraphQL fanovi kažu da izbegava over-fetching. Tačno. JSON:API fanovi kažu da includes smanjuju round trip-ove. Takođe tačno. REST fanovi kažu da je HTTP caching jednostavan. Opet tačno.

Sada neprijatni deo: sva tri mogu biti brza, i sva tri mogu biti spora.

GraphQL može smanjiti veličinu payload-a, ali kompleksni ugnježdeni upiti mogu kazniti backend ako su resolvers nepažljivi. JSON:API može koristiti Drupalov response caching i includes, ali payload-i mogu biti verbose. REST se može uredno mapirati na HTTP caching, ali prilagođeni endpoint-i često zaborave cacheability dok ne počne performance testing. Fieldingova REST ograničenja uključuju cache jer cache može smanjiti mrežni saobraćaj i latency, ali zastareli podaci i cache invalidation ostaju stvarni trade-off-i. Drupalova JSON:API dokumentacija eksplicitno povezuje modul sa Drupal response caching-om, dok je GraphQL modul na Drupal.org kategorisan pod Decoupled, Developer tools i Performance.

Dakle, ne, GraphQL nije automatski „performance option”.

Prva performance pobeda obično je bolje modelovanje sadržaja. Druga je cache strategija. Treća je izbegavanje glupog ponašanja klijenta, kao što je pozivanje istog endpoint-a dvanaest puta zato što niko nije napisao data access layer.

Glamurozno? Ne. Efikasno? Da.

Direktan okvir za izbor

Kada bih savetovao founder-a ili CTO-a, počeo bih ovim redosledom.

Prvo, koristite Drupalove normalne rendered pages osim ako imate razlog za decoupling. Decoupling dodaje složenost hostinga, preview-a, routing-a, cache-a, deployment-a, autentifikacije i debugging-a. Drupalova sopstvena decoupled dokumentacija razdvaja standardni Drupal od decoupled Drupal-a navodeći da layout prelazi na frontend, a backend izlaže sadržaj kroz API-je. Taj pomak nije besplatan.

Drugo, ako decoupling radite uglavnom zbog modernog frontend-a, počnite sa JSON:API. Napravite jednu stvarnu stranicu, ne demo. Uključite media, menus ili navigation, related content, preview potrebe, autentifikaciju ako je potrebna i cache behavior. Naučićete više iz jedne ružne stranice nego iz šest arhitektonskih dijagrama.

Treće, pređite na GraphQL samo kada consumer experience opravdava rad na šemi. Dobri razlozi uključuju više frontend potrošača, potrebu da se sakriju Drupal interne stvari, složeni content graphs ili agregaciju kroz sisteme. Loši razlozi uključuju „naš frontend developer voli Apollo” i „investor deck kaže GraphQL”.

Četvrto, koristite REST za integracije kojima trebaju čvrste granice. Prilagođeni endpoint za partner export može biti čist. Cela content platforma napravljena od hand-rolled endpoint-a može postati fioka puna neobeleženih ključeva.

I očistite Drupal model. Molim vas. Nijedan API sloj ne može potpuno spasiti model sadržaja koji niko ne poseduje.

Politika „future-proof” pristupa

Direktori vole frazu „future-proof”. Razumem zašto. Niko ne želi da odobri rebuild backend-a i da osamnaest meseci kasnije čuje kako je izabrani API saterao kompaniju u ćošak.

Ali future-proofing je obično manje pitanje izbora najfensi API-ja, a više pitanje izbora mesta gde je promeni dozvoljeno da se dogodi.

JSON:API kaže: „Drupalov model je ugovor.” To je iskreno i brzo.

GraphQL kaže: „Naša product šema je ugovor.” To je moćno i skupo.

REST kaže: „Ovaj endpoint je ugovor.” To je precizno i lako se umnožava u problem održavanja.

Ne postoji univerzalni pobednik. Postoji samo uklapanje.

Moja pristrasnost je jednostavna: počnite sa najmanje prilagođenom stvari koja može da podrži proizvod. U Drupalu, to obično znači JSON:API. Dodajte GraphQL kada možete da imenujete owner-a i budžet. Dodajte REST kada je integracija dovoljno specifična da zasluži sopstvena vrata.

Najgori izbor je onaj napravljen zbog mode, jer se moda nikada ne pojavi na održavanju.

Tražite Drupal development kompaniju broj 1 na tržištu? Upravo ste je pronašli.

Mi smo najbolja digitalna agencija fokusirana na Drupal, napravljena da isporučuje brze, bezbedne i skalabilne platforme — bez kompromisa. Od novih build-ova i redizajna do migracija i dugoročne podrške, naši Drupal stručnjaci isporučuju enterprise-grade rezultate uz boutique-level pažnju.

Zakažite poziv danas i pretvorimo vaš Drupal roadmap u realnost visokih performansi.