GraphQL: gamybinė patirtis

2020 m. Jūsų komanda vis labiau linkstama kurti vieno puslapio programas arba bent jau įtraukti daug komponentų į įprastas daugiapuses programas. [GraphQL](https://graphql.org/) jau [daugiau nei dveji metai](https://en.wikipedia.org/wiki/GraphQL), o tai JavaScript ekosistemų standartus būtų galima laikyti brandžiais. Jautėmės šiek tiek drąsūs, todėl atsisakėme įprastų JSON API ir pasinėrėme į jas - štai ką sužinojome.

Reikia GraphQL serverio

Daugumoje sistemų, naudojamų žiniatinklio kūrimas, įrankiai, skirti JSON API jau yra. Galite sukurti maršruto struktūrą ir lengvai priimti keletą GET ir POST, tada išvesti JSON atsakymą. Ruby svetainėje Bėgiai net turi specialų projektas sąrankos perjungiklis, kuriuo atsisakoma įprastų HTML pertvarkymo gudrybių ir vietoj jų sukuriamas tvirtas API pagrindas. Iš to išplaukia, kad įgudęs kūrėjas naudodami šiuolaikinius įrankius galite sukurti pagrindinę versiją per kelias minutes.

Ne taip yra su GraphQL. Nors yra serverio bibliotekų, skirtų daug kalbų, vis tiek iškart patirsite greičio nuostolių - tiesiog turėsite išsiaiškinti, kas tinka jūsų ekosistemai. Kalbant asmeniškiau, man taip pat nepatinka terminas “serveris”, naudojamas bibliotekai, kurią galima įdiegti į projektą, apibūdinti.

Yra tik vienas galutinis taškas

Metams bėgant pripratome prie tam tikro mąstymo apie API struktūrą. Paprasčiausiai laikėmės REST praktikos. Tai reiškė, kad programėlėje kiekvienam loginiam modeliui reikėjo sukurti kelis galinius taškus. Tai struktūra, kurią lengva suvokti ir API autoriams, ir vartotojams. Be to, ji sukuria gerai suskirstytus metodus galinėje dalyje, todėl argumentavimas apie kodas taip pat paprasta, kaip ir apie pačią API. Šią struktūrą taip pat lengva naudoti vardų erdvėje, pvz. API versijų nustatymas.

"GraphQL" naudoja tik vieną galinį tašką, paprastai /graphql. Kiekviena užklausa į jūsų API bus siunčiama kaip POST užklausa į tą galutinį tašką, o GraphQL serverio pareiga - išsiaiškinti, ko klientas nori, ir tinkamai atsakyti.

Iš pirmo žvilgsnio tai atrodo nepatogus sprendimas: įsivaizduokite, kad viską, kas numatyta JSON API, bandote atlikti naudodami vieną galinį tašką! Tačiau netrukus, kai API subręs ir vienus dalykus pakeis kiti, tai pradės įgauti prasmę. Klasikinėse API deprecation paprastai atliekamas vardų erdvės lygmeniu, pereinant nuo v1 į v2. GraphQL suteikia kur kas daugiau galimybių valdyti, net iki vieno lauko panaikinimo. Įsivaizduokite, kad galite pasakyti REST API vartotojui, jog nenorite, kad jis naudotų pavadinimas lauką ir naudoti fancy_name vietoj to! Pasirodo, tai, kas iš pradžių atrodė nepatogu, iš tikrųjų yra viena geriausių funkcijų.

Viskas įvesta

JSON iš tikrųjų neturi daug rašymo būdų. Yra eilutės, skaičiai, masyvai ir objektai. Be to, jums nesiseka. Tuo tarpu GraphQL viskas prasideda ir baigiasi tipais, nes net šakninės užklausos ir mutacijos yra būtent tipai. GraphQL DSL užtikrina tipų tikrinimą ir serveryje, ir kliente, todėl išvengiama įvairių nemalonių netikėtumų.

Tai labai svarbu, ypač dėl to, kad SPA vis dažniau tikrinami tipai, nesvarbu, ar naudojant TypeScript arba alternatyvas, pavyzdžiui, "Flow". "GraphQL" leidžia lengvai įvesti sudėtingus ir sudėtinius tipus ant numatytųjų reikšmių, ir tai greitai tampa antraeiliu dalyku tiek backend, tiek frontend programuotojams.

Skaityti daugiau: JavaScript testavimas... su Ruby?!

Dokumentai yra įmontuoti

Klasikinės JSON API atveju dokumentacija gali būti papildoma. Net jei taip nėra, galima rinktis iš daugybės metodų. Ar naudojame kokią nors schemą, pvz. OpenAPI? Ar tada konvertuosime jį į žmogui suprantamą formą naudodami tokius įrankius kaip "Swagger"? O gal tiesiog kažkur išmesime visą krūvą Markdown failų? Nors ši problema buvo išspręsta daugybę kartų, vis dar reikia sąmoningų team darbuotojų minčių ir pastangų - iš pradžių sukurti dokumentus, o paskui juos nuolat atnaujinti ir platinti. Tai dar sudėtingesnė problema, kai API turi keletą skyrių, kurie yra prieinami tik, pavyzdžiui, tam tikroms naudotojų rolėms.

GraphQL dokumentacija yra pirmos klasės pilietis, nes dauguma serverių leidžia dokumentuoti tipus ir užklausas vietoje. Nuo 2018 m. pradžios GraphQL schemų apibrėžimo kalba tapo oficialios specifikacijos dalimi, todėl yra būtent vienas būdas dokumentuoti GraphQL API. Be to, kadangi GraphQL leidžia apibrėžti tam tikrų grafiko dalių matomumą, tie naudotojai, kurie neturėtų to daryti, automatiškai negali matyti dokumentų, susijusių su tuo, ko jie negali pasiekti. Tai, kad buvo pasirūpinta šiuo sprendimu ir aiškiomis gairėmis, buvo didelė paspirtis team.

Yra tik dvi veiksmų rūšys

Priešingai nei HTTP GET, POST, PUT, PATCH ir DELETE, "GraphQL" yra tik dviejų tipų veiksmai: Užklausos ir mutacijos. Pagrindinis skirtumas yra tas, kad "Mutations" gali keisti ir keičia sistemos būseną, o "Queries" tik pasyviai skaito duomenys iš.

Prisipažinsiu, kad vis dar abejoju, ar tai bus tiesa. Man patinka HTTP veiksmažodžių gausa bendraujant su ištekliais ir galimybė naudoti būtent tą įrankį, kuris tinka darbui. GraphQL palengvina darbą tais sudėtingais atvejais, kai bet kuris iš HTTP veiksmažodžių netiksliai tinka, tačiau tenka mokėti už tai, kad reikia galvoti, ką konkreti mutacija iš tikrųjų paveiks. Taip pat galima pastebėti, kad kadangi nėra įdiegtos standartinės pavadinimų suteikimo konvencijos, teks rengti vidinius stiliaus vadovus arba rizikuoti sukurti nenuoseklią netvarką.

Jums reikia kliento

Sąveikauti su REST API per HTTP yra labai paprasta naudojant "vanilla JavaScript", o dar lengviau - naudojant moderniąją parsisiųsti API. Tuo tarpu GraphQL atveju, jei norite iš tiesų tinkamo našumo, reikia naudoti kliento biblioteką. Nėra neįmanoma sąveikauti su GraphQL API naudojant tik vanilinį JavaScript - juk tai tik POST užklausos. Tačiau naudojant tik ilgametę Tinklalapis technologijos, pavyzdžiui, užklausų spartinančioji talpykla bendriems API skambučiams, neveiks, nes POST užklausos paprastai nėra spartinančiosios talpyklos.

Kiekvienas protingas GraphQL klientas turi kliento pusės rezultatų spartinimo mechanizmą ir daug kitų funkcijų. Dėl visų šių pasirinkimų pradinio lygio GraphQL kliento konfigūracijos sukūrimas ranka yra visiškai neįveikiama užduotis. Pradedantiesiems dirbti su GraphQL ypač rekomenduoju atkreipti dėmesį į Apollo-Boost nes jame yra labai pagrįstos numatytosios reikšmės.

Klientas pasirenka duomenis

Visiems yra buvę taip: iš API ištraukiame duomenų sąrašą ir jame trūksta kokio nors svarbaus susijusio modelio lauko. Tuomet įgyvendiname įsilaužimą, apimantį N+1 užklausą, ir tuo pat metu pykstame ant galinių kūrėjų, kurie skubiai jį įtraukia. Paprastai taip nebūna su gerai įgyvendinta GraphQL API, nes galime tiesiog gilintis į duomenis tiek, kiek norime. Reikia pamatyti užsakyme nurodyto kliento adresą šioje partijoje? Ne problema - bent jau teoriškai, o tai gražiai veda prie to, kad mus į...

Sudėtingumą sunkiau numatyti

Projektuojant GraphQL iš galinės dalies, gali būti sunku apgalvoti, kaip giliai klientas gali įsigilinti į grafą. Yra daugybė būdų, kaip nustatyti ir stebėti, kaip naudojamas jūsų grafas, ir, leidę kolegoms iš priekinės dalies kurį laiką žaisti, galite pradėti stebėti, kaip ilgos užklausos atlieka gana išradingus duomenų skaitymus jūsų duomenų saugykloje. Naudojant REST API tai lengviau kontroliuoti, nes galite lengvai nustatyti duomenų, kurie bus pasiekiami vienos užklausos metu, apimtį. Dažnai šis nepastebėtas sudėtingumas gali skaudžiai atsiliepti, kai paleidžiate į gamybą. Daugeliu atvejų taip pat nėra akivaizdu, kaip išbristi iš šios duobės, kurią patys išsikasėte.

Sunumeruoti puslapiai yra tikrai sunkūs

Iš tikrųjų tai yra tik liežuvio užkalbėjimas. Pažvelgus į numatyto puslapiavimo mechanizmo veikimą, tikrai galima pajusti, kad "GraphQL" buvo sukurta "Facebook" ir jam skirta. Vadinamosios jungtys iš esmės yra nesibaigiantys grafo briaunų srautai, kuriuose navigacija vykdoma naudojant žymeklius, o ne klasikinius puslapius. Nors nesunku suprasti, kaip tai tinka "Facebook" stiliaus nesibaigiančiam pranešimų srautui, jei norite tvarkingai puslapiuoto sąrašo su galimybe pereiti, tarkime, į 42 puslapį, jums bus daug sunkiau. Žinoma, yra būdų, kaip tai apeiti, bet tai ir yra apėjimo būdai.

Ar tai darytume dar kartą?

Turėdami visus pirmiau išvardytus trūkumus ir skirtumus, tikriausiai manote, kad "GraphQL" vertiname kaip eksperimentą, kuris baigėsi nesėkmingai, ir grįžome tiesiai prie REST API. Tai netiesa. Jei ką nors ir darome, tai siekiame, kad "GraphQL" būtų plačiau naudojama visos organizacijos projektuose. Tai puiki technologija, kuri palengvino ir pagerino mūsų darbą. Tačiau iš pradžių investavome į "GraphQL" visiškai nesuprasdami, kokius augimo skausmus teks patirti.

Jei manote, kad GraphQL gali būti jums tinkama, raginu ryžtis šiam žingsniui. Suteikite sau pakankamai laiko ir erdvės saugiai patirti nesėkmę, ir netrukus galėsite naudotis privalumais!

Taip pat skaitykite:

- Kaip veiksmingai valdyti nuotolinius kūrėjus? CTO vadovas

- Python vs. Ruby? Kurią technologiją turėtumėte naudoti produktui kurti?

- Trumpas vadovas, kaip sukurti ir plėtoti savo rinką. Ką verta žinoti?