GraphQL vs. REST pro enterprise commerce (2027)

REST je styl aplikačního programového rozhraní, tedy web API, který zpřístupňuje více pevných koncových bodů, z nichž každý vrací data v předem dané podobě. GraphQL funguje jako dotazovací jazyk a architektura rozhraní s jediným koncovým bodem, což umožňuje klientovi přesně určit, jaká data potřebuje získat v rámci jediného dotazu.

Rozhodování GraphQL vs. REST má pro web řadu přímých dopadů, protože ovlivňuje objem přenášených dat mezi systémy, počet potřebných síťových požadavků na stránku i flexibilitu integrací v průběhu času. Shopify stanovil GraphQL jako své oficiální API v říjnu 2024. V roce předcházejícím tomuto rozhodnutí došlo ke zdvojnásobení limitů pro přenosy GraphQL a ke snížení nákladů na propojené dotazy o 75 %.

Tento průvodce popisuje, v čem se obě architektury liší a do jakých situací se hodí. Nabízí také rozhodovací rámec pro technické a obchodní týmy, které mezi těmito přístupy volí.

REST: tradiční přístup

E-commerce API umožňuje výměnu dat mezi systémy. Klient odešle požadavek na koncový bod na serveru a server mu odpoví daty.

Zkratka REST znamená Representational State Transfer a API postavená na tomto principu se označují jako RESTful API nebo REST API. Jejich počátky sahají do raných let 21. století a staly se standardem pro webové služby, protože ke komunikaci a přenosu dat používají standardní metody HTTP jako GET, POST, PUT a DELETE.

REST nabízí jasné přednosti, které vysvětlují jeho přetrvávající oblibu:

• Předvídatelné koncové body: Každý zdroj má vlastní URL, takže něco jako /products/123 vždy znamená totéž.
• Široká podpora nástrojů: Každý jazyk, každá brána i monitorovací nástroj rozumí RESTu.
• Známé stavové kódy HTTP: Kód 404 nebo 429 klientovi sdělí, co se stalo, aniž by musel analyzovat tělo odpovědi.
• Nativní HTTP cachování: Protože každý požadavek GET má stabilní URL, prohlížeče, sítě pro doručování obsahu (CDN) i proxy servery dokážou odpovědi cachovat bez dalšího úsilí.

REST spolehlivě funguje u jednodušších operací orientovaných na zdroje, ať už jde o webhooky, nahrávání souborů, veřejná data určená pouze pro čtení nebo integrace, kde tento přístup partnerské nástroje přímo vyžadují. Průzkum State of the API od společnosti Postman z roku 2025 potvrdil, že REST stále aktivně využívá 93 % vývojářských týmů.

V prostředích s vysokými nároky na výkon se však u RESTu projevují jeho limity. Koncové body totiž vracejí předem danou sadu dat, což vede ke dvěma typickým komplikacím:

• Overfetching (získání nadbytečných dat): Koncový bod může vrátit celý záznam o produktu, i když klient potřebuje pouze stavy skladu.
• Underfetching (získání nedostatečných dat): Koncový bod nemusí vrátit vše, co klient potřebuje, takže klient musí odeslat několik dotazů na různé koncové body, aby sestavil jeden ucelený přehled.

Jediná stránka se přitom může potýkat s overfetchingem i underfetchingem současně.

S rozvojem mobilních zařízení i cloudových technologií v průběhu uplynulého desetiletí se tato neefektivita stávala stále citelnější. Technologické týmy, pro které byla klíčová optimalizace rychlosti webu, proto začaly hledat jiné řešení a přišly s novým konceptem.

GraphQL: efektivnější alternativa

Facebook zahájil vývoj GraphQL v roce 2012 při kompletní přestavbě svých mobilních aplikací a v roce 2015 uvolnil tuto technologii jako open source. Od roku 2018 specifikaci nezávisle spravuje GraphQL Foundation v rámci Linux Foundation. Dnes toto řešení pohání přední webové platformy po celém světě.

Při srovnání GraphQL vs. REST řeší GraphQL problémy s overfetchingem a underfetchingem zavedením flexibilního dotazovacího jazyka. Klientská aplikace si řekne pouze o konkrétní pole a server vrátí přesně požadovaný rozsah dat, nic navíc a nic méně.

Jak funguje schéma GraphQL

Rozhraní GraphQL je definováno schématem. Schéma popisuje každý typ v systému, například Product, Variant, Order nebo Customer, i konkrétní atributy, které jednotlivé typy nabízejí. Současně definuje vazby mezi nimi, díky čemuž dokáže jediný dotaz načíst data z objednávky, jednotlivých položek i přiřazených produktů bez nutnosti odesílat separátní požadavky.

Schéma podporuje tři základní typy operací:

• Dotazy (queries) čtou data.
• Mutace je vytvářejí, aktualizují nebo mažou.
• Odběry (subscriptions) posílají klientovi aktualizace, když se data změní.

Díky silnému typování schématu prověří GraphQL server každý požadavek ještě před jeho spuštěním a okamžitě odmítne dotazy na neexistující pole.

Schéma je navíc introspektivní. Klient se může rozhraní přímo zeptat na jeho vlastní strukturu. Na tomto principu staví automatické doplňování kódu v nástrojích typu GraphiQL a vývojových prostředích (IDE). Díky tomu dokážou zachytit syntaktické chyby ještě před odesláním požadavku.

Zde je praktický příklad dotazu zaměřeného na e-shop. Dotaz požaduje název produktu, první dvě varianty s cenou i dostupností a hlavní produktový obrázek:

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

Odpověď přesně kopíruje strukturu zadaného dotazu. Pole, která klient v dotazu neuvedl, jako jsou podrobné popisy produktů, štítky nebo SEO metadata, server vůbec nepřenáší. V případě RESTu by klient obdržel standardní fixní odpověď a pro doplňující informace, například vlastní pole či metadata, by musel volat další samostatné koncové body.

Popularita GraphQL rychle roste, protože výzvu, kterou řešil Facebook v počátcích, dnes řeší většina digitálních projektů. Cílem je vytvářet komplexní aplikace pracující s velkým objemem dat, které zůstávají rychlé a stabilní. Tento požadavek dnes řeší jak začínající e-shopy, tak globální korporace.

Šest výhod používání GraphQL pro firemní e-commerce

Rozdíly mezi architekturami GraphQL vs. REST se mohou zpočátku zdát nepatrné, ale API představuje základní stavební kámen každého moderního e-shopu. Podobně jako základy stavby může správně zvolené API zajistit dlouhodobou stabilitu nebo naopak přinést strukturální komplikace při dalším rozvoji a údržbě systému. Tyto limity se naplno projevují při vysokém zatížení a jsou zřetelné především ve firemní sféře.

Zde je přehledné srovnání hlavních parametrů:

Vysoká flexibilita GraphQL s sebou nese specifické nároky. Protože strukturu dotazu určuje klient, nevhodně sestavený požadavek může server zatížit výrazně více než běžné volání REST. Aplikační server musí provést více výpočetních operací, potřebuje resolvery pro jednotlivá pole a mechanismy bránící hluboce zanořeným dotazům, které by přetížily databázi.

Firemní týmy přecházející na GraphQL potřebují nastavit jasná pravidla pro návrh schémat i provádění dotazů. To zahrnuje limity na výpočetní náročnost dotazů, omezení hloubky zanoření a odpovědnost za správu schématu. Tyto parametry je vhodné začlenit přímo do technického zadání pro ecommerce software již od počátku projektu.

Následující části popisují výhody, díky nimž je GraphQL silnou volbou tam, kde se hodí nejvíce: rozmanití klienti, propojené datové modely, více zdrojů dat a nákupní zážitky citlivé na výkon.

1. Vhodný pro komplexní data

Data ve větších e-commerce projektech vytvářejí síť vzájemně propojených entit, kterou lze popsat jako graf. Produkt obsahuje jednotlivé varianty a každá z nich eviduje skladové zásoby na různých pobočkách. Objednávka se váže na zákaznické účty, aplikované slevy a logistické procesy. Firemní B2B zákaznický portál navíc pracuje s individuálními ceníky a specifickými splatnostmi. REST tyto provázané struktury zplošťuje do samostatných koncových bodů rozdělených podle jednotlivých entit. S rostoucím objemem dat se zvyšuje i počet volání rozhraní nutných k sestavení jednoho zobrazení a latence roste společně se složitostí systému.

GraphQL vznikl právě pro efektivní práci s takto propojenými daty. Schéma popisuje vzájemné vazby přímo, takže jediný dotaz dokáže vrátit přesně požadovaná data v rámci jedné síťové operace. Z toho důvodu tvoří GraphQL základ jednotného datového modelu platformy Shopify.
Značka Tecovas, která prodává westernovou módu a obuv, potřebovala systém kombinující stabilní jádro s rozsáhlými možnostmi přizpůsobení. „Hledám systémy, které vyřeší každodenní provoz, ale zároveň nabízejí rozšiřitelnost, robustní sadu API a možnost přizpůsobení našim konkrétním obchodním procesům,“ uvádí technický ředitel společnosti Tecovas Kevin Harwood.

Tecovas nasadil pos systém od Shopify jako centrální nástroj pro sledování skladů. Personál na prodejně tak může okamžitě ověřit dostupnost konkrétního kusu, jakmile projeví zákazník zájem. Vlastní e-shop značky běží na headless frameworku Shopify Hydrogen, který načítá data o produktech, kolekcích i nákupním košíku přímo přes Storefront API postavené na GraphQL.

2. Snížený přenos dat

Koncové body REST vracejí předem definovaný soubor dat, který často převyšuje skutečné potřeby klienta, což vede k overfetchingu. Zbytečný přenos nepožadovaných dat zatěžuje síť a prodlužuje odezvu aplikace.

U větších komerčních projektů hrají roli i zlomky sekund. Každých 32 milisekund zpoždění při reakci obchodu na akci uživatele může snížit celkový konverzní poměr přibližně o 1,5 %.

GraphQL omezuje přenos pouze na položky výslovně uvedené v dotazu. Eliminací nadbytečných dat dosahují systémy napojené přes GraphQL nižšího vytížení přenosových tras a vyšší stability při špičkách.

3. Méně cest na server

Jelikož koncové body REST neumožňují zacílit pouze na vybrané atributy, zobrazení jedné stránky často vyžaduje sérii dílčích požadavků, což představuje typický underfetching. Každé takové volání znamená samostatnou cestu na server a zpět.

Názorným příkladem je standardní produktová stránka. V rozhraní REST Admin API od Shopify vrací koncový bod fixní strukturu údajů o zboží, přičemž doplňková data, jako jsou vlastní metapole, vyžadují samostatné požadavky. Sestavení celého detailu produktu tak může znamenat několik po sobě jdoucích volání, z nichž každé navíc přenáší data, která daná stránka vůbec nepotřebuje. Stejný pohled vyřeší jediný dotaz GraphQL, který si vyžádá pouze potřebná pole.

Vynásobte to synchronizací katalogu, integrací systému plánování podnikových zdrojů (ERP) nebo pokladní aplikací (POS), která kontroluje zásoby v reálném čase. Rozdíl je měřitelný. Méně cest na server a zpět znamená rychlejší načítání a plynulejší uživatelský zážitek.

4. Lepší zážitek pro vývojáře

REST je mnoha vývojářům dobře známý díky své dlouhé historii. GraphQL po nich zpočátku může vyžadovat více úsilí, ale vrátí jim to zpět v podobě nástrojů. Schéma je silně typované a funguje jako vlastní dokumentace. Vývojáři mohou snadno prozkoumat neznámé API, využívat automatické doplňování kódu a zachytit chyby ještě před spuštěním dotazu. Pevně dané schéma navíc dlouhodobě pomáhá udržovat integritu dat.

Existují nuance, se kterými by firemní týmy měly počítat:

• Zpracování chyb: GraphQL vrací stavový kód HTTP 200, i když část dotazu selže, s podrobnostmi v poli errors. GraphQL Admin API od Shopify tento rozdíl výslovně dokumentuje. Klienti proto musí vyhodnocovat tělo odpovědi a nespoléhat se pouze na stavové kódy.
• Složitost serveru: Každé pole vyžaduje vlastní resolver. Naivní resolvery mohou spustit jeden databázový dotaz na každou položku v seznamu (tzv. problém „N+1“). Řešením jsou dávkovací a cachovací vrstvy, které je však potřeba vytvořit.
• Pravidla a řízení provozu: Klienti si píší vlastní dotazy, takže vlastník API musí zveřejnit limity pro náklady nebo hloubku dotazů. Úpravy schématu také vyžadují kontrolu napříč příslušnými týmy. Admin API od platformy Shopify například omezuje přenosy podle vypočítaných nákladů dotazu, nikoli podle počtu požadavků.

5. Snazší vývoj API

Rozhraní API se s časem přirozeně mění. V případě RESTu znamená zásadní změna struktury odpovědi novou verzi, například v2, a nutnost migrace pro každou klientskou aplikaci.

GraphQL umožňuje rozvíjet schéma bez nutnosti číslovat verze. Nová pole lze přidávat kdykoli, aniž by to ovlivnilo stávající klienty, protože ti dostávají pouze data, o která si výslovně požádali. Starší pole se označují direktivou o zastarání, která data stále poskytuje, ale vývojáře upozorňuje přímo v jejich nástrojích. Odstraněná pole pak vrátí chybu už během validace ještě před spuštěním dotazu.

To neznamená, že k větším úpravám nedochází. Z tohoto důvodu Shopify nadále verzuje svá API na čtvrtletní bázi. GraphQL však odstraňuje nutnost vytvářet novou verzi celého rozhraní pokaždé, když se změní jedno pole.

6. Vyšší výkon

Při zvažování architektury GraphQL vs. REST mohou všechny tyto přednosti působit abstraktně. Jak se tedy projevují ve skutečném provozu? Na vzorku téměř 200 000 veřejně dostupných datových bodů se obchody na Shopify vykreslují až 2,4krát rychleji a v průměru 1,8krát rychleji než obchody, pro které byla zvolena jiná e-commerce platforma.

GraphQL představuje pouze jeden z faktorů vysoké rychlosti Shopify, nikoli její jediné vysvětlení. Výsledné tempo načítání vychází z celého technického základu, do kterého patří globální hosting, doručování přes CDN, cachování v prohlížeči, komprese i optimalizace obrázků pro web. GraphQL snižuje celkový objem přenášených dat a počet síťových požadavků, zatímco platforma zajišťuje maximální rychlost načítání zbývající části stránky.

Shopify a GraphQL

Shopify začal GraphQL využívat brzy poté, co jej Facebook veřejně uvolnil. V té době existovalo jen minimum osvědčených postupů a jako jeden z prvních průkopníků se Shopify učil s touto architekturou pracovat od úplných základů. Od té doby obliba GraphQL výrazně vzrostla a technologie se stala klíčovým pilířem infrastruktury Shopify, z čehož přímo těží i samotné obchody.

V říjnu 2024 Shopify oznámil, že se GraphQL stává jeho definitivním standardem rozhraní API. Od 1. dubna 2025 musí všechny nové aplikace odesílané do Shopify App Store využívat výhradně GraphQL. Původní REST Admin API sice zůstává funkční, ale nese status legacy, tedy zastaralé. Nové funkce platformy vycházejí přednostně v GraphQL a řada z nich je dostupná pouze v tomto rozhraní, například podpora až 2 000 variant produktu nebo metaobjekty.

Storefront API staví přímo na GraphQL a Admin API je přes něj plně dostupné. Nástroje jako Shopify Functions, rozšíření uživatelského rozhraní nebo App Bridge rovněž pracují s GraphQL jako se svým výchozím API.

Souběžný provoz během firemní migrace

Modernizace platformy nevyžaduje okamžitý převod všech integrací naráz. Dočasný souběžný provoz obou architektur v rámci strategie GraphQL vs. REST je plně podporován, což potvrzuje i přístup značky Skullcandy při jejím přechodu.

Společnost Skullcandy dokončila migraci na Shopify během 90 dní (případovou studii si můžete přečíst v angličtině). Původní pětikrokový nákupní proces nahradil optimalizovaný Shopify Checkout a značka mohla zcela opustit samostatný systém pro správu produktových informací (PIM). Běžné zpracování objednávek zajišťuje REST API společně s webhooky. Naproti tomu hromadné úpravy skladů probíhají přes GraphQL API, které dokáže aktualizovat stovky skladových položek v jediném volání namísto postupného odesílání jednotlivých požadavků. Kombinace rozhraní REST a GraphQL navíc pohání i nově vyvíjené aplikace.

Výsledky značky Skullcandy se po přechodu na Shopify dostavily okamžitě. Doba načítání domovské stránky klesla hned den po spuštění z 2,8 sekundy na pouhých 0,8 sekundy. První kompletní vánoční sezóna přinesla značce na nové platformě meziroční růst tržeb o 45 %. Největší produktový launch pak způsobil 200% nárůst návštěvnosti, aniž by došlo k jakémukoli zakolísání rychlosti webu.

Kdy použít GraphQL vs. REST?

REST i GraphQL jsou dnes v Shopify v produkčním provozu. Je třeba učinit praktické rozhodnutí, který z nich pro kterou zátěž použít.

GraphQL zvolte, když práce zahrnuje:

• Komplexní datové modely: Produkty s mnoha variantami, zásoby na více místech, B2B ceníky nebo metaobjekty, které je třeba získat společně
• Rozmanité klienty: Web, mobil, POS a AI agenty, z nichž každý potřebuje jiný výsek stejných dat
• Vlastní e-shopy: Headless řešení na Hydrogen nebo jiném frameworku, kde rychlost stránky závisí na minimalizaci požadavků
• Dlouhodobé integrace: Propojení s ERP, systémy pro správu objednávek (OMS) a PIM, která se budou muset vyvíjet roky, aniž by se rozbila

REST se stále hodí v situacích, kdy:

• Operace je jednoduché čtení nebo zápis jediného zdroje
• Nástroje partnera očekávají REST, nebo je integrace již vytvořená a stabilní
• Jde o webhooky nebo nahrávání souborů

Využití obou přístupů během postupné migrace dává plný smysl. Stávající integrace na RESTu můžete nechat běžet a nový vývoj rovnou směřovat do GraphQL. Nejprve přesuňte procesy s nejvyšším objemem dat nebo nejvyšší technickou složitostí, kde se výhody projeví nejvíce. Tuto posloupnost berte jako součást promyšlené IT transformace, nikoli jako překotný jednorázový přepis celého kódu.

Pro větší e-commerce projekty na platformě Shopify představuje GraphQL dlouhodobě silnější volbu. Právě pro toto rozhraní vznikají veškeré nové funkce a staví na něm i vlastní nativní nástroje Shopify.