Dyskusja mi\u0119dzy GraphQL a REST to cz\u0119sto sp\u00f3r ideologiczny. Kto\u015b powie: „GraphQL to przysz\u0142o\u015b\u0107, pozwoli Ci zaoszcz\u0119dzi\u0107 na transferze danych”. Inny odparuje: „REST jest prostszy i sprawdzony, nie komplikuj”. Prawda jak zwykle le\u017cy po \u015brodku, ale niestety \u2013 w praktyce widz\u0119, \u017ce wiele firm przep\u0142aca ogromne kwoty tylko dlatego, \u017ce pope\u0142niaj\u0105 jeden z trzech podstawowych b\u0142\u0119d\u00f3w przy wyborze i implementacji API. W JurskiTech na co dzie\u0144 pomagamy klientom optymalizowa\u0107 aplikacje webowe i cz\u0119sto spotykamy te same pu\u0142apki. Oto one.<\/p>\n
GraphQL kusi elastyczno\u015bci\u0105 \u2013 klient mo\u017ce zapyta\u0107 dok\u0142adnie o to, czego potrzebuje, i dosta\u0107 tylko to. Brzmi jak marzenie. Tyle \u017ce za t\u0119 swobod\u0119 p\u0142acisz z\u0142o\u017cono\u015bci\u0105 i kosztami po stronie serwera. Je\u015bli Twoja aplikacja ma kilka prostych endpoint\u00f3w, np. pobieranie listy produkt\u00f3w, szczeg\u00f3\u0142\u00f3w zam\u00f3wienia, dodanie do koszyka \u2013 GraphQL wprowadza niepotrzebn\u0105 warstw\u0119 abstrakcji.<\/p>\n
Przyk\u0142ad z \u017cycia<\/strong> \u2013 przyszed\u0142 do nas klient z ma\u0142ym sklepem e-commerce. Mia\u0142 oko\u0142o 20 zapyta\u0144 do API. Postawili na GraphQL, bo \u201eto teraz modne\u201d. Po miesi\u0105cu okaza\u0142o si\u0119, \u017ce serwer nie wyrabia\u0142 \u2013 ka\u017cde zapytanie musia\u0142o przej\u015b\u0107 przez resolver, a przy wi\u0119kszej liczbie p\u00f3l zapytania stawa\u0142y si\u0119 ci\u0119\u017ckie. Rachunek za chmur\u0119 wzr\u00f3s\u0142 o 40% w por\u00f3wnaniu do poprzedniego REST API.<\/p>\n Dlaczego? GraphQL wymaga bardziej z\u0142o\u017conego przetwarzania po stronie backendu. Ka\u017cde zapytanie to potencjalnie wiele zapyta\u0144 do bazy danych (problem N+1). Rozwi\u0105zania jak DataLoader pomagaj\u0105, ale kosztuj\u0105 czas i pieni\u0105dze na implementacj\u0119. Je\u015bli Twoje API jest proste i stabilne, REST b\u0119dzie ta\u0144szy \u2013 zar\u00f3wno w utrzymaniu, jak i w mocy obliczeniowej.<\/p>\n Kiedy wi\u0119c GraphQL? Gdy masz wiele r\u00f3\u017cnych klient\u00f3w (aplikacja mobilna, web, smartwatch) i chcesz da\u0107 im elastyczno\u015b\u0107 w pobieraniu danych. Albo gdy Twoja domena jest bardzo z\u0142o\u017cona, np. dashboard analityczny z dynamicznymi filtrami. Ale je\u015bli robisz prosty CRUD \u2013 trzymaj si\u0119 REST.<\/p>\n REST od lat ma jedn\u0105 gigantyczn\u0105 przewag\u0119 \u2013 natywne wsparcie dla cache’owania. Dzi\u0119ki nag\u0142\u00f3wkom HTTP (ETag, Cache-Control, Last-Modified) mo\u017cesz zminimalizowa\u0107 liczb\u0119 zapyta\u0144 do serwera. W GraphQL domy\u015blnie nie ma cache’owania na poziomie HTTP \u2013 ka\u017cde zapytanie to POST, a wi\u0119c nie jest buforowane przez przegl\u0105dark\u0119 czy CDN.<\/p>\n Spotka\u0142em si\u0119 z sytuacj\u0105, gdzie firma maj\u0105ca aplikacj\u0119 z REST API narzeka\u0142a na powolno\u015b\u0107. Okaza\u0142o si\u0119, \u017ce nie u\u017cywali \u017cadnego cache’owania. Wystarczy\u0142o doda\u0107 ETag na niekt\u00f3re endpointy i ruch spad\u0142 o 70%. Rachunki za serwer zmala\u0142y r\u00f3wnie drastycznie.<\/p>\n W GraphQL mo\u017cesz zastosowa\u0107 cache na poziomie aplikacji (np. Apollo Client ma cache po stronie klienta, a na serwerze mo\u017cesz u\u017cy\u0107 narz\u0119dzi jak GraphQL Cache), ale to dodatkowa z\u0142o\u017cono\u015b\u0107 i koszty. Je\u015bli nie masz konkretnej potrzeby, by rezygnowa\u0107 z REST \u2013 nie rezygnuj.<\/p>\n Rada praktyczna<\/strong> \u2013 zanim przejdziesz na GraphQL, policz, czy oszcz\u0119dno\u015bci na transferze danych przewy\u017csz\u0105 koszty dodatkowej mocy serwera i braku prostego cache’owania. Dla wielu aplikacji ma\u0142ych i \u015brednich firm odpowied\u017a brzmi: nie.<\/p>\n To chyba najcz\u0119stszy b\u0142\u0105d. Przechodzisz na GraphQL, ale piszesz endpointy 1:1 jak w REST \u2013 osobne zapytanie dla ka\u017cdego zasobu. Wtedy tracisz g\u0142\u00f3wn\u0105 zalet\u0119 GraphQL \u2013 \u0142\u0105czenie danych w jednym zapytaniu. Tw\u00f3j klient i tak musi zrobi\u0107 kilka round-trip\u00f3w, a serwer wci\u0105\u017c wykonuje wiele zapyta\u0144.<\/p>\n Z drugiej strony \u2013 widzia\u0142em REST API, kt\u00f3re pr\u00f3bowa\u0142o na\u015bladowa\u0107 GraphQL, dodaj\u0105c opcjonalne parametry do jednego endpointu. Efekt? Gigantyczne, nieczytelne endpointy, kt\u00f3re zwracaj\u0105 wszystko lub prawie wszystko. To prowadzi do prze\u0142adowania danych (over-fetching) i wolnych odpowiedzi.<\/p>\n Przyk\u0142ad<\/strong> \u2013 klient mia\u0142 REST API z endpointem W GraphQL chodzi o to, \u017ceby zaprojektowa\u0107 schemat wok\u00f3\u0142 przypadk\u00f3w u\u017cycia, a nie tabel w bazie danych. Je\u015bli potrzebujesz pobra\u0107 u\u017cytkownika i jego zam\u00f3wienia, zr\u00f3b jedno zapytanie, kt\u00f3re to \u0142\u0105czy. Je\u015bli w REST potrzebujesz dw\u00f3ch zapyta\u0144, to OK \u2013 nie kombinuj.<\/p>\n REST sprawdza si\u0119, gdy:<\/p>\n GraphQL jest lepszy, gdy:<\/p>\n Wyb\u00f3r mi\u0119dzy GraphQL a REST to nie kwestia mody, tylko rachunku ekonomicznego. W JurskiTech cz\u0119sto spotykamy firmy, kt\u00f3re przep\u0142acaj\u0105 za chmur\u0119 lub trac\u0105 czas na implementacj\u0119 niepotrzebnych rozwi\u0105za\u0144. Je\u015bli zastanawiasz si\u0119 nad zmian\u0105 \u2013 zr\u00f3b audyt swojego API. Policz koszty, zmierz czas odpowiedzi, sprawd\u017a, jak cz\u0119sto dane si\u0119 zmieniaj\u0105. Cz\u0119sto okazuje si\u0119, \u017ce REST z dobrze skonfigurowanym cache’em jest ta\u0144szy i szybszy ni\u017c GraphQL.<\/p>\n A je\u015bli ju\u017c musisz i\u015b\u0107 w GraphQL \u2013 zadbaj o ochron\u0119 przed zbyt ci\u0119\u017ckimi zapytaniami (limit g\u0142\u0119boko\u015bci, limit z\u0142o\u017cono\u015bci) i monitoruj koszty. Ka\u017cdy bajt ma swoj\u0105 cen\u0119.<\/p>\n","protected":false},"excerpt":{"rendered":" GraphQL vs REST: 3 b\u0142\u0119dy, kt\u00f3re winduj\u0105 koszty Twojej aplikacji Dyskusja mi\u0119dzy GraphQL a REST to cz\u0119sto sp\u00f3r ideologiczny. Kto\u015b powie: „GraphQL to przysz\u0142o\u015b\u0107, pozwoli Ci zaoszcz\u0119dzi\u0107 na transferze danych”. Inny odparuje: „REST jest prostszy i sprawdzony, nie komplikuj”. Prawda jak zwykle le\u017cy po \u015brodku, ale niestety \u2013 w praktyce widz\u0119, \u017ce wiele firm przep\u0142aca<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[699,1003,57,58,602],"class_list":["post-2776","post","type-post","status-publish","format-standard","hentry","category-warto-wiedziec","tag-api-gateway","tag-debugowanie-wydajnosci","tag-graphql","tag-koszty-it","tag-rest"],"_links":{"self":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2776","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/comments?post=2776"}],"version-history":[{"count":0,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2776\/revisions"}],"wp:attachment":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/media?parent=2776"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/categories?post=2776"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/tags?post=2776"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}B\u0142\u0105d 2: Ignorowanie cache’owania w REST (i brak go w GraphQL)<\/h3>\n
B\u0142\u0105d 3: Projektowanie GraphQL API jak REST (i odwrotnie)<\/h3>\n
\/users\/:id<\/code> i do niego doczepi\u0142 opcjonalne parametry: ?include=orders,?include=address. W rezultacie endpoint sta\u0142 si\u0119 wolny, a testowanie \u2013 koszmarem. Lepszym rozwi\u0105zaniem by\u0142oby osobne zapytanie do \/users\/:id\/orders<\/code> z cache’owaniem.<\/p>\nKiedy wi\u0119c co wybra\u0107?<\/h3>\n
\n
\n
Podsumowanie<\/h3>\n