1. diel - GraphQL - GraphQL vs. REST

GraphQL

Počas posledného desaťročia sa REST stal štandardom (síce nejasným) pre navrhovanie webových API. Ponúka mnoho nápadov, ako sú bezstavové servery a štruktúrovaný prístup. Postupom času sa však ukázal ako príliš neflexibilný, aby dokázal držať krok s rýchlo sa meniacimi požiadavkami klientov, ktorí ho používajú. GraphQL bol vyvinutý, aby sa vyrovnal s potrebou väčšej flexibility a efektivity.

Svetlo sveta GraphQL uzrelo roku 2012. Autorom je firma Facebook, ktorá ho vyvinula pre potrebu efektívnej a rýchlej komunikácie medzi mobilnými zariadeniami. V roku 2015 bol kód uvedený ako opensource a teraz je vo vlastníctve GraphQL Foundation. GraphQL nájdeme u mnohých veľkých firiem ako sú Facebook, GitHub, Pinterest, Intuícia, Coursera, Shopify, Paypal a ďalšie.

Čo je to a na čo je to dobré?

Väčšina aplikácií dnes potrebuje získavať dáta zo servera, kde sú tieto dáta uložené v databáze. Zodpovednosťou API je poskytnúť rozhranie pre uložené dáta, ktoré zodpovedá potrebám aplikácie. GraphQL je často zamieňaný za databázovú technológiu, čo je mylná predstava. GraphQL je dotazovací jazyk pre naše API a behové prostredie na strane servera, pre vykonávanie dotazov podľa jasne definovanej typovej schémy.

Typová schéma presne definuje formát dát, ktoré si budú klient a server medzi sebou vymieňať. GraphQL je multiplatformný. Môžeme ho použiť v čistom Javascripte alebo nasadiť do nášho obľúbeného frameworku ako sú Angular, Vue alebo React. Je možné ho používať so širokou škálou programovacích jazykov ako sú PHP, Java / Kotlin, Python, Perl, C#/.NET, C / C++ a mnoho ďalších.

Prečo GraphGL, keď máme REST?

Hlavná výhoda spočíva v jedinom prístupovom bode. V RESTe je pre každý zdroj dát zvláštny prístupový bod. Ako príklad si môžeme ukázať API pre aplikáciu na blogovanie. Predstavme si situáciu, kedy na strane klienta budeme chcieť zobraziť naraz používateľa, jeho meno a posledné 3 sledujúce daného používateľa. Prístupové body by mohli vyzerať takto:

Na načítanie dát užívateľa	GET /uzívateľ/<id>
Zoznam napísaných príspevkov užívateľom	GET /uzívateľ/<id>/pris­pevky
Zoznam sledujúcich užívateľov	GET /uzívateľ/<id>/nas­ledujúci

V REST u potrebujeme 3 kroky na načítanie potrebných dát:

Na získanie potrebných dát je potrebné sa pripojiť ku všetkým trom prístupovým bodom a stiahnuť všetky dáta. Vrátane tých, ktoré nepotrebujeme.

V GraphQL nám stačí jedna presne formulovaná otázka:

V RESTe sú ďalšou úrovňou HTTP Verb. Najpoužívanejšie sú na čítanie, zápis, úpravu a mazanie dát (GET, POST, PUT a DELETE). V GraphQL sa používa základný Query (otázka), ktorý zastáva funkciu načítania dát. Pre všetko ostatné, ako je úprava, vkladanie a mazanie dát sa používa Mutation (mutácia).

REST	GraphQL
GET	Query
POST, UPDATE, DELETE	Mutation

Výhody systému schém a typov

GraphQL využíva silný typový systém na definovanie schopností API. Všetky typy, ktoré sú vystavené v rozhraní API, sú zapísané do schémy pomocou GraphQL jazyka SDL (S chema D efinition L anguage). Táto schéma je ako zmluva medzi klientom a serverom, ktorá definuje, ako môže klient pristupovať k údajom. Akonáhle je schéma definovaná, tímy pracujúce na frontende a backende môžu robiť svoju prácu bez ďalšej komunikácie, pretože obaja poznajú presnú štruktúru dát odosielaných cez sieť, čím sa vyvarujú prehnanému alebo nedostatočnému načítaniu dát.

Overfetching a underfetching

Jedným z najčastejších problémov REST je práve preťaženie a nedostatočné načítanie dát. K tomu dochádza, pretože jediný spôsob, ako môže klient stiahnuť dáta, je naraziť na koncové body, ktoré vracajú pevné dátové štruktúry. Navrhnúť také API, ktoré by poskytovalo presné dátové potreby klientom je veľmi ťažké.

Overfetching znamená, že klient stiahne viac dát ako je skutočne potrebné. Ak potrebujeme zobraziť iba zoznam mien užívateľov, koncový bod nám vráti polia JSON, ktoré môžu obsahovať viac informácií, než len tie, ktoré sú potrebné.

Opačným problémom je underfetching a požiadavka n+1. Underfetching všeobecne znamená, že konkrétny koncový bod neposkytol dostatok požadovaných informácií. Klient musí vykonať ďalšie požiadavky, aby získal všetko čo potrebuje. Nakoniec to môže vyeskalovať, keď klient stiahne zoznam prvkov. Potom pre každý prvok musí vykonať ešte ďalšiu požiadavku, aby získal potrebné dáta.

Rýchla zmena na frontende

Bežným vzorom s rozhraním REST je štruktúrovanie koncových bodov podľa zobrazenia, ktoré máme vo svojej aplikácii. To je užitočné, pretože umožňuje klientovi získať všetky požadované informácie pre konkrétny pohľad jednoduchým prístupom k zodpovedajúcemu koncovému bodu. Hlavnou nevýhodou tohto prístupu je, že neumožňuje rýchlu zmenu na frontende. S každou zmenou, ktorá je vykonaná v užívateľskom rozhraní, existuje vysoké riziko, že je teraz potrebných viac (alebo menej) dát ako predtým. V dôsledku toho je potrebné upraviť aj backend, aby zohľadnil nové potreby dát. S GraphQL je tento problém vyriešený. Vďaka flexibilite je možné zmeny vykonávať bez akejkoľvek zmeny na serveri.

Nevýhody?

Rovnako ako aj v iných oblastiach je každá kladná vlastnosť vyvážená inou negatívnou. Nevýhodou jediného prístupného bodu je ten, že nie je možné sa jednoduchým dotazom opýtať na všetky dáta, napríklad ako pri jazyku SQL (príkazom SELECT * FROM table;). Pokiaľ chceme získať všetky dostupné dáta, je potrebné vymenovať všetky atribúty.

Pri používaní RESTu sme si navykli používať HTTP statusy v odpovediach a prípadne na ne reagovať na frontend. Pri GraphQL môžeme iba počítať s HTTP statusom 400 pri chybnej požiadavke a pre všetko ostatné je HTTP status 200. Ostatné chyby, ktoré môžu nastať, budú zapísané v JSON odpovedi.

Príklad chyby na neexistujúcu otázku:

{
    "data": null,
    "errors": [
        {
            "message": "Validation error of type FieldUndefined: Field 'ahoj' in type 'Query' is undefined @ 'ahoj'",
            "locations": [
                {
                    "line": 2,
                    "column": 5,
                    "sourceName": null
                }
            ],
            "description": "Field 'ahoj' in type 'Query' is undefined",
            "validationErrorType": "FieldUndefined",
            "queryPath": [
                "ahoj"
            ],
            "errorType": "ValidationError",
            "path": null,
            "extensions": null
        }
    ]
}

V budúcej lekcii, Dátové typy, schéma a otázky v GraphQL , sa pozrieme na primitívne dátové typy, základnú konštrukciu schémy a ukážeme a vyskúšame si prvé otázky.