GraphQL ir REST palyginimas el. prekyboje (2027 m.)

REST – tai svetainėms skirtas programų sąsajos (API) stilius, kuriame yra keli fiksuoti galutiniai taškai, o kiekvienas jų grąžina nustatytą duomenų struktūrą. GraphQL yra užklausų kalba ir API architektūra, kurioje atveriamas vienas galutinis taškas, o klientas gali tiksliai nurodyti, kokių duomenų jam reikia, naudodamas vieną užklausą.

Pasirinkimas tarp REST ir GraphQL turi nemažai pasekmių jūsų svetainei, įskaitant tai, kiek duomenų keliauja tarp jūsų sistemų, kiek užklausų reikia vienam puslapiui ir kaip laikui bėgant kinta jūsų integracijos. 2024 m. spalį „Shopify“ paskelbė GraphQL savo pagrindine API. Prieš priimdami šį sprendimą, per metus padvigubinome GraphQL dažnio apribojimus ir 75 % sumažinome ryšiu grįstų užklausų kainą.

Šiame vadove aptariama, kuo skiriasi GraphQL ir REST ir kur geriausiai tinka kiekviena jų. Jame taip pat pateikiama sprendimų priėmimo sistema stambaus verslo prekybos komandoms, kurios renkasi tarp šių dviejų variantų.

REST: tradicinis būdas

El. prekybos API tvarko duomenų mainus tarp sistemų. Klientas siunčia užklausą serverio galutiniam taškui, o serveris atsako duomenimis.

REST reiškia „Representational State Transfer“, o jo pagrindu sukurtos API vadinamos RESTful arba REST API. Jos atsirado dar XXI amžiaus pradžioje ir tapo žiniatinklio paslaugų standartu, nes bendravimui ir duomenų perdavimui naudoja standartinius HTTP metodus, pavyzdžiui, GET, POST, PUT ir DELETE.

REST turi aiškių privalumų, kurie paaiškina, kodėl ji vis dar taip plačiai naudojama:

• Nuspėjami galutiniai taškai: kiekvienas išteklius turi savo URL adresą, todėl kažkas panašaus į /products/123 visada reiškia tą patį.
• Platus įrankių pasirinkimas: REST supranta kiekviena programavimo kalba, tinklų sietuvas ir stebėjimo įrankis.
• Pažįstami HTTP būsenos kodai: kodas 404 arba 429 pasako klientui, kas atsitiko, nereikalaujant analizuoti atsakymo turinio.
• Įgimtas HTTP talpyklos palaikymas: kadangi kiekviena GET užklausa turi pastovų URL adresą, naršyklės, turinio pateikties tinklai (CDN) ir tarpiniai serveriai gali kaupti atsakymus talpykloje be papildomų pastangų.

REST vis dar gerai tinka paprastoms, ištekliais grįstoms operacijoms: žiniatinklio kabliukams (angl. webhooks), failų įkėlimams, viešiesiems tik skaitymui skirtiems duomenims ir integracijoms, kurioms to tikisi partnerio naudojami įrankiai. „Postman“ 2025 m. ataskaitoje „State of the API" nustatyta, kad 93 % komandų vis dar naudoja REST.

Vis dėlto tam tikrose didelės apkrovos situacijose REST atskleidžia savo trūkumus. REST galutiniai taškai grąžina fiksuotą duomenų rinkinį, o tai gali sukelti dvi susijusias problemas:

• Perteklinė duomenų gavyba (angl. overfetching): galutinis taškas gali grąžinti visą produkto įrašą, nors klientui reikia tik atsargų lygių.
• Nepakankama duomenų gavyba (angl. underfetching): galutinis taškas gali grąžinti ne visus klientui reikalingus duomenis, todėl klientui tenka kreiptis į kelis galutinius taškus, kad surinktų vieną vaizdą.

Vienas puslapis gali kentėti ir nuo perteklinės, ir nuo nepakankamos duomenų gavybos vienu metu.

XXI amžiaus pirmąjį ir antrąjį dešimtmetį augant mobiliesiems ir debesų kompiuterijos sprendimams, šios problemos ėmė ryškėti. Galiausiai viena bendrovė, patirianti milžinišką spaudimą padidinti svetainės greitį, sugalvojo kai ką naujo.

GraphQL: efektyvesnė alternatyva

„Facebook“ pradėjo kurti GraphQL 2012 m., kai iš naujo kūrė savo mobiliąsias programas, o 2015 m. pavertė ją atvirojo kodo projektu. Nuo 2018 m. specifikaciją prižiūri „GraphQL Foundation“, kurios veiklą globoja „Linux Foundation“. Dabar ją naudoja pagrindinės žiniatinklio platformos visame pasaulyje.

GraphQL sprendžia perteklinės ir nepakankamos duomenų gavybos problemas, būdingas REST API, nes įveda užklausų kalbą. Klientas prašo tik tų duomenų, kurių jam reikia, o serveris grąžina būtent tai, ko buvo paprašyta – nei daugiau, nei mažiau.

Kaip veikia GraphQL schema

GraphQL API apibrėžia schema. Schemoje deklaruojami visi sistemos tipai (pavyzdžiui, Product, Variant, Order ir Customer) ir laukai, kuriuos atskleidžia kiekvienas tipas. Joje taip pat deklaruojami ryšiai tarp jų, todėl viena užklausa gali gauti duomenis apie užsakymą, jo eilutes ir kiekvieną produktą, nereikalaujant atskiros užklausos.

Schema palaiko tris operacijų tipus:

• Užklausos (angl. „queries“) nuskaito duomenis.
• Mutacijos (angl. „mutations“) juos sukuria, atnaujina arba ištrina.
• Prenumeratos (angl. „subscriptions“) siunčia klientui atnaujinimus, kai duomenys pasikeičia.

Kadangi schema yra griežtai tipizuota, GraphQL serveris patvirtina kiekvieną užklausą prieš ją vykdydamas ir atmeta viską, kas prašo neegzistuojančio lauko.

Schemą taip pat galima tirti. Klientas gali paprašyti API apibūdinti pačią save – būtent tai įgalina automatinį užbaigimą tokiuose įrankiuose kaip „GraphiQL“ ir leidžia programavimo aplinkoms (IDE) pažymėti klaidas dar prieš įvykdant užklausą.

Štai prekybai pritaikytas užklausos pavyzdys. Užklausa prašo produkto pavadinimo, pirmųjų dviejų jo variantų su kaina ir atsargomis bei produkto pagrindinio vaizdo:

{ product(handle: "trail-runner") { title featuredImage { url } variants(first: 2) { nodes { title price { amount currencyCode } availableForSale } } } }

Atsakymas atkartoja užklausą. Laukai, kurių klientas neprašė (pavyzdžiui, aprašymai, žymos ar SEO metaduomenys), serverio niekada nepalieka. Naudojant REST, klientas gauna produkto galutinio taško iš anksto nustatytą atsakymo struktūrą ir turi atskirai kreiptis dėl bet kokių duomenų, kurių atsakyme nėra, pavyzdžiui, metalaukų.

GraphQL išpopuliarėjo, nes problema, su kuria „Facebook“ susidūrė anksti, dabar būdinga daugeliui bendrovių: poreikis kurti sudėtingas, duomenų gausias programas, kurios kartu būtų greitos ir stabilios. Dabar ši problema vienodai aktuali ir mažiausioms internetinėms parduotuvėms, ir didžiausiems stambaus verslo prekių ženklams.

Šeši GraphQL naudojimo stambaus verslo prekyboje privalumai

Skirtumai tarp GraphQL ir REST gali atrodyti nedideli, tačiau API yra prekybos svetainės veikimo pamatas. Kaip ir namo pamatas, pasirinkta API gali užtikrinti ilgalaikį stabilumą arba sukelti struktūrinių problemų kuriant ir prižiūrint visa kita. Tokios problemos labiausiai pastebimos ir reikšmingos tampa dirbant dideliu mastu, o ypač ryškios yra stambaus verslo prekyboje.

Štai pagrindinių skirtumų santrauka:

Žinoma, GraphQL lankstumas turi ir trūkumų. Kadangi užklausą valdo klientas, viena prastai parašyta užklausa gali būti kur kas brangesnė už bet kurį REST iškvietimą. Serveris taip pat atlieka daugiau darbo: jam reikia kiekvieno lauko sprendiklių (angl. resolvers) ir apsaugos nuo įdėtinių užklausų, kurios sukelia daugybę duomenų bazės paieškų.

Stambaus verslo komandoms, pasirenkančioms GraphQL, reikia aiškaus ir griežto schemos projektavimo bei užklausų elgsenos valdymo. Tai reiškia užklausų kainos ir gylio apribojimus bei bendrą atsakomybę už schemą. Įtraukite tai į savo stambaus verslo programinės įrangos reikalavimus nuo pat pradžių.

Toliau pateikiamuose skyriuose aprašomi privalumai, dėl kurių GraphQL yra tvirtas pasirinkimas ten, kur jis tinka labiausiai: įvairūs klientai, susieti duomenų modeliai, keli duomenų šaltiniai ir greičiui jautri apsipirkimo patirtis.

1. Tinka sudėtingiems duomenims

Stambaus verslo prekybos duomenys sudaro tarpusavyje susijusių objektų tinklą, kurį galima pavaizduoti kaip grafą. Produktas turi variantų, o kiekvienas variantas turi atsargų keliose vietose. Užsakymas susijęs su klientais, nuolaidomis ir vykdymais. B2B paskyra turi savo kainoraščius ir mokėjimo sąlygas. REST suplokština šias duomenų struktūras į atskirus kiekvieno ištekliaus galutinius taškus. Augant duomenų modeliui, didėja ir API iškvietimų, reikalingų vienam vaizdui surinkti, skaičius. Delsa auga kartu su grafu.

GraphQL buvo sukurta būtent tokiems duomenims. Schema tiesiogiai aprašo ryšius, todėl viena užklausa gali grąžinti būtent tuos duomenis, kurių reikia vaizdui. Būtent todėl GraphQL yra svarbi „Shopify“ vieningo duomenų modelio dalis.

„Tecovas“, vakarietiško stiliaus drabužių mažmenininkui, reikėjo sistemos, kuri šalia pagrindinių funkcijų siūlytų ir galingas API. „Ieškau sistemų, kurios išspręstų man kasdienes problemas, bet kartu suteiktų galimybę plėstis, patikimą API rinkinį ir gebėjimą pritaikyti sprendimus mūsų konkretiems verslo procesams“, – sako „Tecovas“ vyriausiasis technologijų vadovas Kevinas Harwoodas.

„Tecovas“ naudoja „Shopify POS“ kaip visiškai integruotą atsargų sistemą. Darbuotojai gali patikrinti naujausius atsargų lygius, kai pirkėjas pasiteirauja apie konkrečią prekę. Jų individuali internetinė parduotuvė sukurta naudojant „Shopify Hydrogen“, kuri kreipiasi į GraphQL „Storefront API“ dėl produktų, kolekcijų ir krepšelio duomenų.

2. Sumažintas duomenų perdavimas

REST galutiniai taškai grąžina fiksuotą duomenų rinkinį, kuris gali būti didesnis, nei klientui reikia (perteklinė duomenų gavyba). Grąžinti daugiau duomenų, nei būtina, yra neefektyvu ir gali sukurti delsą.

Stambaus verslo prekyboje svarbios net milisekundės. Kiekvienai 32 milisekundėms lėtesniam parduotuvės atsakui į veiksmus konversija paprastai sumažėja maždaug 1,5 %.

GraphQL apriboja duomenų gavybą tik tais laukais, kurių prašo klientas. Sumažindamos nereikalingą duomenų perdavimą, GraphQL API naudojančios sistemos gali sumažinti pralaidumo naudojimą ir pagerinti našumą.

3. Mažiau kreipimųsi į serverį

Kadangi REST galutiniai taškai negali nutaikyti tikslių duomenų taškų, vienam vaizdui gali prireikti kelių užklausų (nepakankama duomenų gavyba). Kiekvienai užklausai reikia pilno kreipimosi į serverį.

Produkto puslapis yra geras pavyzdys. „Shopify“ REST „Admin API“ produkto atsakymas gaunamas kaip vienas fiksuotas duomenų paketas, o susijusiems duomenims, pavyzdžiui, metalaukams, reikia papildomų užklausų. Todėl visam produkto vaizdui surinkti gali prireikti kelių kreipimųsi į galutinius taškus, o kiekvienas jų grąžina laukus, kurių puslapis nenaudos. Tam pačiam vaizdui užtenka vienos GraphQL užklausos, kuri įvardija tik jai reikalingus laukus.

Padauginkite tai iš katalogo sinchronizavimo, įmonės išteklių planavimo (ERP) integracijos ar pardavimo vietos (POS) programos, realiu laiku tikrinančios atsargas. Skirtumas yra išmatuojamas. Mažiau kreipimųsi reiškia greitesnį įkėlimą ir sklandesnę naudotojo patirtį.

4. Geresnė kūrėjų patirtis

REST daugeliui kūrėjų yra pažįstama dėl savo ilgos istorijos. GraphQL iš pradžių gali pareikalauti daugiau, tačiau tai atsiperka įrankiais. Schema yra griežtai tipizuota ir pati save dokumentuojanti. Kūrėjas gali tyrinėti nepažįstamą API, automatiškai užbaigti užklausas ir pastebėti klaidas dar prieš ką nors paleisdamas. Griežtai tipizuota schema taip pat padeda laikui bėgant išlaikyti duomenų vientisumą.

Yra niuansų, kuriuos stambaus verslo komandos turėtų numatyti:

• Klaidų tvarkymas: GraphQL grąžina HTTP 200 net ir tada, kai dalis užklausos nepavyksta, o išsamesnė informacija pateikiama errors masyve. „Shopify“ GraphQL „Admin API“ aiškiai aprašo šį skirtumą. Klientai turi tikrinti atsakymo turinį, o ne pasikliauti būsenos kodais.
• Serverio sudėtingumas: kiekvienam laukui reikia sprendiklio. Primityvūs sprendikliai gali sukelti po vieną duomenų bazės užklausą kiekvienam sąrašo elementui (vadinamoji „N+1“ problema). Grupavimo ir talpyklos sluoksniai ją išsprendžia, bet kažkas turi juos sukurti.
• Valdymas: klientai rašo savo užklausas, todėl API savininkas turi paskelbti užklausų kainos ar gylio apribojimus. Schemos pakeitimus taip pat turi peržiūrėti atitinkamos komandos. „Shopify“ „Admin API“, pavyzdžiui, riboja dažnį pagal apskaičiuotą užklausos kainą, o ne pagal užklausų skaičių.

5. Paprastesnė API raida

Laikui bėgant API keičiasi. Naudojant REST, nesuderinamas atsakymo struktūros pakeitimas reiškia naują versiją (/v2/) ir migracijos laikotarpį kiekvienam klientui.

GraphQL sukurta taip, kad schema galėtų keistis be versijų numerių. Nauji laukai gali būti pridedami bet kuriuo metu. Esamiems klientams tai neturi įtakos, nes jie gauna tik tuos laukus, kurių paprašė. Seni laukai pažymimi pasenimo direktyva, kuri vis dar grąžina duomenis, bet įspėja kūrėjus jų įrankiuose. Pašalinti laukai patvirtinimo metu grąžina klaidą dar prieš įvykdant užklausą.

Tai nereiškia, kad nesuderinami pakeitimai tampa neįmanomi. Būtent dėl to „Shopify“ vis tiek versijuoja savo API kas ketvirtį. GraphQL panaikina poreikį versijuoti visą API kiekvieną kartą, kai pasikeičia vienas laukas.

6. Pagerintas našumas

Visi šie privalumai gali atrodyti abstraktūs, tad kaip jie pasireiškia realiu našumu? Remiantis beveik 200 000 viešai prieinamų duomenų taškų, „Shopify“ parduotuvės atvaizduojamos iki 2,4 karto greičiau, o vidutiniškai – 1,8 karto greičiau nei kitų platformų parduotuvės.

Žinoma, GraphQL yra tik viena iš „Shopify“ greitį lemiančių dalių, o ne visas paaiškinimas. Svetainės greitį lemia ir pati platforma: pasaulinė prieglobos infrastruktūra, pateiktis per CDN, naršyklės talpykla, glaudinimas ir vaizdų optimizavimas. GraphQL sumažina puslapiui reikalingų duomenų ir kreipimųsi kiekį. Platforma nulemia, kaip greitai pasieks likusi puslapio dalis.

„Shopify“ ir GraphQL

„Shopify“ pradėjo naudoti GraphQL, kai „Facebook“ ją viešai išleido. Tuo metu geriausios praktikos beveik nebuvo, todėl, būdami vieni iš pirmųjų pritaikytojų, GraphQL išmokome nuo pamatų. Nuo tada GraphQL tapo kur kas populiaresnė ir dar svarbesnė „Shopify“ infrastruktūrai, o „Shopify“ internetinės parduotuvės iš to gavo naudos.

2024 m. spalį paskelbėme, kad GraphQL taps pagrindine „Shopify“ API. Nuo 2025 m. balandžio 1 d. visos naujos programos, pateikiamos „Shopify App Store“, privalo naudoti GraphQL. REST „Admin API“ pažymėta kaip pasenusi, nors ir toliau veikia. Naujos platformos funkcijos pirmiausia pasirodo GraphQL versijoje, o kai kurios yra skirtos tik GraphQL, pavyzdžiui, 2 000 produkto variantų ir metaobjektų palaikymas.

„Storefront API“ naudoja GraphQL, o „Admin API“ prieinama per GraphQL. Tokie įrankiai kaip „Functions“, UI plėtiniai ir „App Bridge“ naudoja GraphQL kaip pagrindinę API sąsają.

Abiejų naudojimas stambaus verslo migracijos metu

Platformos modernizavimas nereikalauja perkelti visų integracijų vienu metu. Lygiagretus REST ir GraphQL naudojimas tam tikrą laikotarpį yra palaikomas – būtent taip prie savo pokyčio priėjo „Skullcandy“.

„Skullcandy“ per 90 dienų migravo į „Shopify“. Jie pakeitė penkių žingsnių individualią atsiskaitymo sistemą „Shopify Checkout“ sprendimu ir atsisakė atskiros produktų informacijos valdymo (PIM) sistemos. Užsakymų apdorojimas veikia naudojant REST API ir žiniatinklio kabliukus. Masiniai atsargų pakeitimai vykdomi per GraphQL API, vienu iškvietimu atnaujinant šimtus atsargų įrašų vietoj po vieną. Tos pačios REST ir GraphQL sąsajos maitina naujas programas.

Perėjus prie „Shopify“, „Skullcandy“ rezultatai buvo akimirksniu pastebimi. Jų pagrindinio puslapio įkėlimo laikas kitą dieną po paleidimo sumažėjo nuo 2,8 iki 0,8 sekundės. Pirmasis pilnas šventinis sezonas „Shopify“ platformoje atnešė „Skullcandy“ 45 % metinį pajamų augimą. Didžiausias jų produkto pristatymas sukėlė 200 % apsilankymų šuolį be jokių našumo problemų.

Kada naudoti GraphQL, o kada – REST

Šiandien „Shopify“ naudoja ir REST, ir GraphQL. Reikia priimti praktinį sprendimą, kurią jų naudoti kiekvienam darbo krūviui.

Rinkitės GraphQL, kai darbas apima:

• Sudėtingus duomenų modelius: produktus su daugybe variantų, kelių vietų atsargas, B2B kainoraščius ar metaobjektus, kuriuos reikia gauti kartu.
• Įvairius klientus: žiniatinklį, mobiliuosius įrenginius, POS ir DI agentus, kuriems kiekvienam reikia skirtingos tų pačių duomenų dalies.
• Individualias internetines parduotuves: „headless“ sprendimus, sukurtus naudojant „Hydrogen“ ar kitą karkasą, kur puslapio greitis priklauso nuo užklausų kiekio mažinimo
• Ilgaamžes integracijas: ERP, užsakymų valdymo sistemų (OMS) ir PIM jungtis, kurios turės keistis metų metus nesugesdamos.

REST vis dar tinka, kai:

• operacija yra paprastas vieno ištekliaus nuskaitymas arba įrašymas;
• partnerio įrankiams reikia REST arba integracija jau sukurta ir stabili;
• susiję žiniatinklio kabliukai ar failų įkėlimai.

Abiejų naudojimas migracijos metu yra įmanomas. Galite palikti veikti esamas REST integracijas, kol naujas darbas pradedamas GraphQL. Pirmiausia perkelkite didžiausios apimties ar sudėtingiausias integracijas, kur nauda didžiausia. Laikykite šią seką platesnio IT transformacijos plano dalimi, o ne vienkartiniu perrašymu.

„Shopify“ stambaus verslo prekybai GraphQL tam tikromis aplinkybėmis yra tvirtesnis pasirinkimas. Būtent šioje API pasirodo naujos funkcijos ir aplink ją sukurti pačios „Shopify“ įrankiai.