Rinkitės pagal tai, kas naudoja API ir kokie įvairūs jų duomenų poreikiai — o ne pagal madą. GraphQL laimi, kai daug įvairių klientų turi formuoti savo duomenis; REST laimi, kai užklausos vienodos, kešuojamos ir paprastos.
Rinkitės pagal tai, kas naudoja API ir kokie įvairūs jų duomenų poreikiai — o ne pagal madą. GraphQL laimi, kai daug įvairių klientų turi formuoti savo duomenis; REST laimi, kai užklausos vienodos, kešuojamos ir paprastos.
user -> posts -> comments) vietoj N REST kreipinių.GET modelis triviai kešuojasi kiekviename sluoksnyje; GraphQL reikia persisted queries, kad priartėtų.| Aspektas | GraphQL | REST |
|---|---|---|
| Over/under-fetching | Išspręsta dizainu | Dažna problema |
| HTTP/CDN kešavimas | Sunku (reikia darbo) | Natūralu ir lengva |
| Užklausų kainos/DoS kontrolė | Turite pridėti patys | Natūraliai apribota |
| Kliento lankstumas | Aukštas | Žemas |
| Serverio sudėtingumas | Didesnis | Mažesnis |
Jie taip pat nėra vienas kitą paneigiantys — daugelis sistemų atveria REST viešiems/kešuojamiems endpointams ir GraphQL turtingiems vidiniams klientams.
Senior interviuotojai tikrina nuovoką, o ne ištikimybę. Stiprus atsakymas įvardija ašis — klientų įvairovę, kešavimo poreikius, komandos brandą, DoS paviršių — ir pripažįsta realias GraphQL kainas (kešavimą ir užklausų kainos kontrolę), o ne pardavinėja jį kaip visuotinai geresnį.
IT pokalbių klausimų biblioteka su išsamiais atsakymais — nuo Junior iki Senior.
Paaukoti