GraphQL: lærdómar af framleiðslu

Það er 2020. Þitt lið er sífellt hneigðari til að byggja einbladsforrit, eða að minnsta kosti innlima rík samsetningarhluta í venjuleg fjölbladsforrit. [GraphQL](https://graphql.org/) er nú [yfir tveggja ára gamalt](https://en.wikipedia.org/wiki/GraphQL), sem með JavaScript Viðmið vistkerfa mætti telja fullþroskuð. Við vorum dálítið ævintýralúðar, svo við slepptum hinum hefðbundnu JSON-API-um og sökkvum beint í verkið – hér er það sem við lærðum.

Þú þarft GraphQL-þjónustuna.

Í flestum rammaskipulögum sem notuð eru til vefþróun, verkfærin til að búa til JSON forritaskil eru þegar til. Þú getur byggt upp slóðauppbyggingu og auðveldlega tekið við nokkrum GET- og POST-beiðnum, og síðan skilað JSON-svari. Rúbín á Relsar hefur jafnvel sérstakt verkefni setja upp rofa sem sleppir venjulegum HTML-útfærsluaðgerðum og leggur traustan grunn fyrir API í staðinn. Það sem fylgir er að fær þróunaraðili Með því að nota nútímaleg verkfæri er hægt að smíða bakenda á bókstaflega nokkrum mínútum.

Ekki er svo með GraphQL. Þó að til séu netþjónabókasöfn fyrir mörg tungumál, Þú lendir samt í hraðaviðurlögum strax frá byrjun – einfaldlega vegna þess að þú þarft að komast að því hvað hentar vistkerfi þínu. Á persónulegra nótum líkar mér heldur ekki að hugtakið “þjónn” sé notað um bókasafn sem hægt er að bæta við verkefni.

Það er aðeins einn endapunktur.

Í gegnum árin höfum við vanist ákveðinni hugsunarhætti varðandi uppbyggingu API. Á grundvallarstigi fylgdum við einfaldlega REST-venjum. Það þýddi að búa til nokkra endapunkta fyrir hvert rökrænt líkan í forritinu okkar. Þetta er uppbygging sem er auðveld fyrir bæði API-höfunda og neytendur að skilja. Hún skapar einnig vel afmörkuð aðferðir í bakendanum, sem gerir rökhugsun um kóði eins auðvelt og varðandi API-ið sjálft. Þessi uppbygging er einnig auðveld til nafnarýmisgreiningar, t.d. í þeim tilgangi að Útgáfustjórnun API.

GraphQL notar aðeins eina endapunkt, venjulega /graphql. Öll beiðni til API-sins þíns berst sem POST-beiðni á þeim endapunkti, og þaðan er það á ábyrgð GraphQL-þjónsins að ákvarða hvað viðskiptavinurinn vill og svara viðeigandi hátt.

Við fyrstu sýn virðist það klunnalegt: ímynda þér að reyna að gera allt í JSON API með einum endapunkti! Hins vegar fer það fljótlega að verða skiljanlegt þegar API-ið þitt þroskast og sumar hlutir eru skipt út fyrir aðra. Úrelding í hefðbundnum API-um er venjulega gerð á nafnarýmisstigi, með því að færa frá útgáfa eitt til v2. GraphQL veitir mun meiri stjórn, allt að því að úrelda eitt einasta reit. Ímyndaðu þér að geta sagt neytanda REST-API að þú viljir ekki að þeir noti nafn völl og að nota fancy_name Í staðinn! Það kemur í ljós að það sem virtist klunnalegt í fyrstu er í raun einn af bestu eiginleikunum.

Allt er slegið inn

JSON hefur í raun ekki mikið af gerðaskilgreiningum. Það eru strengir, tölur, fylki og hlutir. Fyrir utan það ertu án gæfu. Í GraphQL er allt frá upphafi til enda byggt á gerðum, enda eru jafnvel rótar-Query og rótar-Mutation einmitt gerðir. GraphQL DSL krefst gerðaprófunar bæði á þjóninum og viðskiptavininum og kemur þannig í veg fyrir alls konar óþægilega óvænta atburði.

Þetta er mjög mikilvægt, sérstaklega þar sem SPA-arnir eru sífellt meira gerðarskoðaðir sjálfir, hvort sem það er með því að nota TypeScript eða valkostir eins og Flow. GraphQL gerir það auðvelt að kynna flóknar og samsettar tegundir ofan á sjálfgefnar gildi og það verður fljótt eðlislægt forriturum bæði á bakenda og framanenda.

Lesa meira: Prófun JavaScript…með Ruby?!

Skjölin eru innbyggð

Í klassísku JSON API getur skjölunin verið síðasta sem hugsað er um. Og jafnvel þó svo sé ekki, eru til margar aðferðir til að velja úr. Eigum við að nota einhvern skema eins og OpenAPI? Breytum við því þá í mannlesanlegt form með verkfærum eins og Swagger? Eða sleppum við bara hrúgu af Markdown-skrám einhvers staðar? Þrátt fyrir að þetta vandamál hafi verið leyst mörgum sinnum krefst það samt meðvitaðrar hugsunar og fyrirhafnar frá team – fyrst til að byggja skjölin, síðan til að halda þeim uppfærðum og dreifðum. Þetta er enn flóknara vandamál þegar API-ið hefur nokkra kafla sem aðeins er aðgengilegt notendahlutverkum, t.d. ákveðnum notendahlutverkum.

Í GraphQL er skjölun fyrsta flokks borgari þar sem flestir netþjónar leyfa að skrá gerðir og beiðnir beint í kerfinu. Frá byrjun árs 2018 hefur GraphQL Schema Definition Language verið hluti af opinberri forskrift, svo aðeins er til ein leið til að skjalfesta GraphQL API. Einnig þar sem GraphQL gerir kleift að skilgreina sýnileika ákveðinna hluta grafsins, eru notendur sem ekki ættu að hafa aðgang sjálfkrafa hindraðir í að sjá skjölun fyrir það sem þeir geta ekki nálgast. Að hafa ákvörðunina tekin og skýr leiðbeiningakerfi hefur verið mikill ávinningur fyrir team.

Það eru aðeins tvær tegundir aðgerða.

Ólíkt HTTP GET, POST, PUT, PATCH og DELETE eru aðeins tvær gerðir aðgerða í GraphQL: fyrirspurnir og breytingar. Helsti munurinn er sá að breytingar geta og munu breytt ástandi kerfisins, en fyrirspurnir munu aðeins passíft lesa. gögn Út.

Ég verð að viðurkenna að ég er enn á tveimur áttum með þetta. Mér finnst gaman af fjölmörgum sagnorðum HTTP til að eiga samskipti við auðlindir og af því að geta notað nákvæmlega réttan verkfæri fyrir verkið. GraphQL gerir það auðveldara að takast á við þessi flóknu tilfelli þar sem enginn HTTP-sagnorð hentaði nákvæmlega, en það krefst þess að hugsa um hvað tiltekin breyting mun í raun hafa áhrif á. Einnig má benda á að þar sem engin innbyggð staðlað nafngiftarregla er til staðar, þarf að semja innri stílhandbækur eða eiga á hættu að skapa óskipulagðan ringulreið.

Þú þarft eiginlega viðskiptavin.

Að eiga samskipti við REST-API yfir HTTP er einstaklega auðvelt í vanilla JavaScript, enn auðveldara með því að nota hið nútímalega sækja API. Í samanburði viljið þið nota viðskiptavinarbókasafn fyrir GraphQL ef þið viljið virkilega góðan árangur. Það er ekki ómögulegt að eiga samskipti við GraphQL API með því að nota eingöngu vanilla JavaScript – það eru jú bara POST-beiðnir. Hins vegar, með því að nota eingöngu langvarandi Vefur Tækni eins og beiðnigeymsla fyrir algengar API-beiðnir mun ekki virka þar sem POST-beiðnir eru almennt ekki geymdar.

Allir skynsamlegir GraphQL-viðskiptavinir innleiða viðskiptavinahliðarkerfi til að geyma niðurstöður í skyndiminni, auk margra annarra eiginleika. Þökk sé öllum þessum valkostum er það algjörlega yfirþyrmandi verkefni að búa til stillingar handvirkt fyrir GraphQL-viðskiptavin á byrjunarstigi. Þegar þú byrjar með GraphQL mæli ég sérstaklega með að kíkja á Apolló-örvun þar sem það kemur með mjög sanngjörnum sjálfgefnum stillingum.

Viðskiptavinur velur gögnin

Við höfum öll verið þarna: við drögum út lista af gögnum úr API-inu og þar vantar mikilvægt reiti um tengt módel. Við útfærum þá hack sem krefst N+1 beiðna og kvörtum yfir bakendaþróunaraðilunum sem flýta sér við að bæta hann inn. Þetta er yfirleitt ekki raunin með vel útfærðu GraphQL API, þar sem við getum einfaldlega kafað ofan í gögnin eins djúpt og okkur lystir. Þarf að sjá heimilisfang viðskiptavinar á pöntun í þessum lotu? Engar áhyggjur – að minnsta kosti í kenningunni, sem leiðir okkur farsælt áfram okkur til…

Flókið er erfiðara að sjá fyrir

Þegar GraphQL er hannað frá bakenda getur verið erfitt að hugsa um alla þá dýpt sem viðskiptavinur getur kafað í grafið. Það eru margar leiðir til að setja upp mælingartól og fylgjast með notkun grafsins, og eftir að hafa látið forendafólkið þitt leika sér í smástund ferðu að sjá nokkrar langar fyrirspurnir sem framkvæma nokkuð ímyndunaríkar lestraraðgerðir á gagnageymslunni þinni. Í REST-API er þetta auðveldara að stjórna þar sem þú getur auðveldlega tilgreint umfang gagna sem verður sótt í einni beiðni. Oft getur þessi vanmetna flækjustig bitnað harðlega á þér þegar þú setur kerfið í framleiðslu. Og oft er ekki augljóst hvernig eigi að komast út úr þessum gildru sem þið hafið grafið ykkur í.

Síður sem eru númeraðar eru mjög erfiðar

Þetta er í raun kaldhæðnisleg kvörtun. Þú getur greinilega skynjað að GraphQL var hannað hjá og fyrir Facebook þegar þú skoðar hvernig ætlaða síðaskiptingarkerfið virkar. Svokölluðu Connections eru í raun endalausir straumar af grafbrúnum, þar sem sigling fer fram með vísitölum í stað hefðbundinna síða. Þó að auðvelt sé að sjá hvernig þetta passar við endalausan straum færslna í Facebook-stíl, ef þú vilt snyrtilegan lista með síðum, þar sem þú getur farið á, segjum, síðu 42, þá er það mun flóknara. Auðvitað eru til leiðir til að komast hjá þessu, en það eru einmitt bara bráðabirgðalausnir.

Væmum við gert það aftur?

Með öllum kvörtunum og mismunum sem taldir eru upp hér að ofan gætirðu haldið að við tökum GraphQL sem misheppnað tilraun og snúum beint aftur til REST-API-a. Það er ekki rétt. Ef eitthvað er, þá vinnum við að því að nota GraphQL víðar í verkefnum um alla stofnunina. Þetta er frábær tækni sem hefur gert vinnu okkar auðveldari og betri. Við fjárfestum þó upphaflega í GraphQL án þess að gera okkur fullkomlega grein fyrir hvaða þroskaerfiðleikar biðu okkar.

Ef þú heldur að GraphQL gæti hentað þér, hvet ég þig til að taka skrefið. Gefðu þér nægan tíma og svigrúm til að mistakast örugglega, og þú munt brátt njóta ávinningsins!

Lesið einnig:

– Hvernig á að stjórna fjarvinnandi forriturum á áhrifaríkan hátt? Leiðarvísir fyrir CTOs

– Python vs. Ruby? Hvaða tækni ættir þú að nota við vöruþróun?

– Stutt leiðarvísir um að byggja og þróa þitt eigið markaðstorg. Hvað er gott að vita?