GraphQL: ražošanā gūtā pieredze

Ir 2020. gads. Jūsu komanda arvien vairāk sliecas veidot vienas lappuses lietojumprogrammas vai vismaz iekļaut bagātīgas komponentes parastās daudzlappušu lietojumprogrammās. [GraphQL](https://graphql.org/) ir [vairāk nekā divus gadus vecs](https://en.wikipedia.org/wiki/GraphQL), kas līdz ar JavaScript ekosistēmas standartus var uzskatīt par nobriedušiem. Mēs jutāmies mazliet drosmīgi, tāpēc atteicāmies no ierastajiem JSON API un ķērāmies klāt - lūk, ko uzzinājām.

Jums ir nepieciešams GraphQL serveris

Lielākajā daļā sistēmu, ko izmanto tīmekļa izstrāde, rīki, lai izveidotu JSON API jau ir. Varat izveidot maršruta struktūru un viegli pieņemt dažus GET un POST pieprasījumus, pēc tam izvadīt JSON atbildi. Rubīns vietnē Sliedes ir pat īpašs projekts iestatīšanas slēdzis, kas atbrīvo no ierastajiem HTML renderēšanas labumiem un tā vietā nodrošina stabilu API pamatu. No tā izriet, ka prasmīgs izstrādātājs izmantojot mūsdienīgus rīkus, varat izveidot backend burtiski dažu minūšu laikā.

Ne tā ir ar GraphQL. Lai gan ir servera bibliotēkas daudzās valodās, tomēr jau no paša sākuma tiek samazināts ātrums, jo jums vienkārši ir jānoskaidro, kas ir piemērots jūsu ekosistēmai. Runājot personiskāk, man arī nepatīk termins “serveris”, ko izmanto, lai aprakstītu bibliotēku, ko var ieviest projektā.

Ir tikai viens galapunkts

Gadu gaitā mēs pieradām pie noteikta veida domāšanas par API struktūru. Visvienkāršākajā līmenī mēs vienkārši ievērojām REST praksi. Tas nozīmēja, ka lietojumprogrammā izveidojām vairākus galapunktus katram loģiskajam modelim. Tā ir struktūra, kas ir viegli saprotama gan API autoriem, gan patērētājiem. Tā arī rada labi skicētas metodes backendā, padarot argumentāciju par kods tikpat vienkārši kā par pašu API. Šo struktūru ir viegli izmantot arī vārdšķirās, piemēram, lai API versiju veidošana.

GraphQL izmanto tikai vienu galapunktu, parasti /graphql. Katrs pieprasījums uz jūsu API tiks nosūtīts kā POST pieprasījums uz šo galapunktu, un GraphQL servera pienākums ir noskaidrot, ko klients vēlas, un atbilstoši atbildēt.

No pirmā acu uzmetiena šķiet, ka tas ir smagnējs: iedomājieties, ka visu, kas ir JSON API, var izdarīt ar vienu galapunktu! Tomēr, kad API kļūst pilnvērtīgāks un dažas lietas tiek aizstātas ar citām, tas drīz vien sāk kļūt jēgpilns. Klasiskajās API nolietojums parasti tiek veikts nosaukumu telpas līmenī, pārejot no v1 uz v2. GraphQL nodrošina daudz lielāku kontroli, līdz pat viena lauka atcelšanai. Iedomājieties, ka varat pateikt REST API lietotājam, ka nevēlaties, lai tas izmantotu lauku nosaukums lauku un izmantot fancy_name tā vietā! Izrādās, ka tas, kas sākumā šķita smagnējs, patiesībā ir viena no labākajām funkcijām.

Viss ir drukāts

JSON nav daudz rakstīšanas iespēju. Ir virknes, skaitļi, masīvi un objekti. Papildus tam jums nav paveicies. Turpretī GraphQL valodā viss sākas un beidzas ar tipiem, jo pat saknes Query un Mutation ir tieši tādi - tipi. GraphQL DSL nodrošina tipu pārbaudi gan serverī, gan klientā, tādējādi novēršot dažādus nepatīkamus pārsteigumus.

Tas ir ļoti svarīgi, jo īpaši tāpēc, ka SPA arvien biežāk tiek pārbaudīti tipi, vai nu izmantojot TypeScript vai alternatīvas, piemēram, Flow. GraphQL ļauj viegli ieviest sarežģītus un saliktus tipus papildus noklusējuma vērtībām, un izstrādātājiem gan backend, gan frontend lietojumprogrammā tas ātri kļūst par otro dabu.

Lasīt vairāk: JavaScript testēšana... ar Ruby?!

Dokumenti ir iebūvēti

Klasiskā JSON API dokumentācija var būt tikai papildu informācija. Un pat ja tā nav, ir daudz metožu, no kurām izvēlēties. Vai mēs izmantojam kādu shēmu, piemēram OpenAPI? Vai mēs to pārvēršam cilvēkam lasāmā formā, izmantojot tādus rīkus kā Swagger? Vai arī mēs vienkārši kaut kur izgāžam veselu kaudzi Markdown failu? Lai gan šī problēma ir risināta vairākkārt, tā joprojām prasa team apzinātu domāšanu un pūles - vispirms, lai izveidotu dokumentus, pēc tam, lai tos atjauninātu un izplatītu. Tā ir vēl sarežģītāka problēma, ja API ir vairākas sadaļas, kas ir pieejamas tikai, piemēram, noteiktām lietotāju lomām.

GraphQL dokumentācija ir pirmās klases pilsonis, jo vairums serveru ļauj dokumentēt tipus un pieprasījumus uz vietas. Kopš 2018. gada sākuma GraphQL shēmu definēšanas valoda ir oficiālās specifikācijas daļa, tāpēc ir tikai viens veids, kā dokumentēt GraphQL API. Turklāt, tā kā GraphQL ļauj definēt noteiktu grafika daļu redzamību, tie lietotāji, kuriem nevajadzētu to darīt, automātiski tiek atturēti no tā, lai redzētu dokumentāciju par to, kam viņi nevar piekļūt. Tas, ka par šo lēmumu ir parūpējušies un ir skaidras vadlīnijas, ir bijis liels ieguvums team.

Ir tikai divu veidu darbības

Atšķirībā no HTTP GET, POST, PUT, PATCH un DELETE GraphQL ir tikai divu veidu darbības: Pieprasījumi un mutācijas. Galvenā atšķirība ir tā, ka Mutācijas var mainīt un mainīs sistēmas stāvokli, bet vaicājumi tikai pasīvi nolasa un nolasa datus. dati ārā.

Es atzīstu, es joprojām esmu uz žoga par šo vienu. Man patīk HTTP vārdu pārpilnība, kas ļauj mijiedarboties ar resursiem un izmantot precīzi piemērotu rīku darbam. GraphQL atvieglo to sarežģīto gadījumu risināšanu, kad kāds no HTTP darbības vārdiem nav precīzi piemērots, taču tas nozīmē, ka ir jādomā par to, ko konkrētā mutācija patiesībā ietekmēs. Var arī norādīt, ka, tā kā nav iebūvēta standarta nosaukšanas konvencija, jums būs jāizstrādā iekšējās stila vadlīnijas vai arī riskējat izveidot nekonsekventu haosu.

Jums ir nepieciešams diezgan daudz klientu

Saskarsme ar REST API, izmantojot HTTP, ir ļoti vienkārša vanilla JavaScript versijā, un vēl vienkāršāka, izmantojot mūsdienīgo programmatūru. iegūt API. Turpretī GraphQL gadījumā, ja vēlaties patiešām pienācīgu veiktspēju, ir jāizmanto klienta bibliotēka. Nav neiespējami mijiedarboties ar GraphQL API, izmantojot tikai vaniļas JavaScript - galu galā tie ir tikai POST pieprasījumi. Tomēr, izmantojot tikai ilgtermiņa Tīmekļa vietne tehnoloģijas, piemēram, pieprasījumu kešēšana parastajiem API izsaukumiem, nedarbosies, jo POST pieprasījumi parasti netiek kešēti.

Katrs saprātīgs GraphQL klients izmanto klienta puses rezultātu kešēšanas mehānismu un daudzas citas funkcijas. Pateicoties visām šīm iespējām, GraphQL klienta konfigurācijas izveidošana ar rokām sākumlīmenī ir pilnīgi apstulbinošs uzdevums. Uzsākot strādāt ar GraphQL, es īpaši iesaku aplūkot Apollo-Boost jo tam ir ļoti saprātīgi noklusējuma iestatījumi.

Klients izvēlas datus

Mēs visi esam piedzīvojuši šādu situāciju: no API izvelkam datu sarakstu, bet tajā trūkst kāda svarīga lauka par saistīto modeli. Tad mēs ieviešam uzlaušanu, kas ietver N+1 pieprasījumu, vienlaikus raustoties uz aizmugures izstrādātājiem, kas steidzīgi to ātri pievieno. Ar labi īstenotu GraphQL API parasti tā nenotiek, jo mēs varam vienkārši iedziļināties datos tik dziļi, cik vien vēlamies. Nepieciešams redzēt klienta adresi pasūtījumā šajā partijā? Nav problēmu - vismaz teorētiski, kas labi vedina uz to, ka mums uz...

Sarežģītību ir grūtāk paredzēt

Veidojot GraphQL no aizmugures puses, var būt grūti apdomāt, cik dziļi klients var iedziļināties grafā. Ir daudz veidu, kā instrumentēt un novērot grafika izmantošanu, un pēc tam, kad esat ļāvuši saviem front-end kolēģiem kādu laiku spēlēties, varat sākt redzēt, ka daži garie vaicājumi veic diezgan izdomas bagātus datu krātuves nolasījumus. Izmantojot REST API, to ir vieglāk kontrolēt, jo jūs varat viegli noteikt datu apjomu, kam tiks piekļūts vienā pieprasījumā. Bieži vien šī neizmantotā sarežģītība var smagi kaitēt, tiklīdz to nododat ražošanā. Daudzos gadījumos nav arī skaidrs, kā izkļūt no šīs bedres, ko esat sev izrakuši.

Numurētas lapas ir ļoti grūti

Šis ir pārmetums, kas patiesībā ir tikai mēles izteiksmē. Skatoties uz to, kā darbojas GraphQL paredzētais lapas veidošanas mehānisms, noteikti var just, ka GraphQL tika izstrādāts Facebook un tieši Facebook vajadzībām. Tā sauktie savienojumi būtībā ir bezgalīgas grafika malu plūsmas, kuru navigācija notiek, izmantojot kursorus, nevis klasiskās lapas. Lai gan ir viegli saprast, kā tas sader ar Facebook stila bezgalīgu ziņojumu plūsmu, ja vēlaties glīti sarindotu sarakstu ar iespēju pāriet, piemēram, uz 42. lapu, jums būs daudz grūtāk. Protams, ir veidi, kā to apiet, bet tie ir tieši tādi, kādi tie ir - apiet.

Vai mēs to darītu vēlreiz?

Ņemot vērā visas iepriekš uzskaitītās problēmas un atšķirības, jūs droši vien domājat, ka GraphQL uzskatām par eksperimentu, kas izrādījās skābs, un atgriezāmies pie REST API. Tā nav taisnība. Ja ne citādi, tad mēs strādājam pie tā, lai GraphQL izmantotu plašāk projektos visā organizācijā. Tā ir lieliska tehnoloģija, kas ir atvieglojusi un uzlabojusi mūsu darbu. Tomēr mēs sākotnēji ieguldījām GraphQL, pilnībā neapzinoties, kādas augšanas sāpes mums nāksies piedzīvot.

Ja domājat, ka GraphQL varētu būt piemērots tieši jums, iesaku jums to izmantot. Dodiet sev pietiekami daudz laika un iespēju droši ciest neveiksmi, un jūs drīz vien gūsiet labumu!

Lasiet arī:

- Kā efektīvi vadīt attālinātos izstrādātājus? CTO rokasgrāmata

- Python vs Ruby? Kura tehnoloģija būtu jāizmanto produktu izstrādei?

- Īss ceļvedis, kā izveidot un attīstīt savu tirdzniecības vietu. Ko ir vērts zināt?