G\u0142\u00f3wnymi powodami, dla kt\u00f3rych Facebook zacz\u0105\u0142 tworzy\u0107 t\u0119 koncepcj\u0119, s\u0105 coraz cz\u0119stsze u\u017cycia urz\u0105dze\u0144 mobilnych, wykorzystywanie urz\u0105dze\u0144 o ma\u0142ej mocy IoT czy s\u0142abe sieci. GraphQL rozwi\u0105zuje te problemy, pozwalaj\u0105c na ograniczanie ilo\u015bci przesy\u0142anych danych do niezb\u0119dnego minimum.<\/p>\n\n\n\n
G\u0142\u00f3wnym za\u0142o\u017ceniem GraphQL jest deklaratywne pobieranie danych, gdzie to klient okre\u015bla, co dok\u0142adnie potrzebuje otrzyma\u0107 w odpowiedzi z API. Zamiast kilku enpoint\u00f3w, z kt\u00f3rych ka\u017cdy zwraca nam inne dane, wystarczy jeden endpoint, kt\u00f3ry w odpowiedzi zwraca dok\u0142adnie to, o co zosta\u0142 odpytany<\/strong>.<\/p>\n\n\n\n Z dalszej cz\u0119\u015bci artyku\u0142u dowiesz si\u0119, kiedy wykorzystywa\u0107 GraphQL, a kiedy REST API oraz w czym GraphQL ma przewag\u0119.<\/p>\n\n\n\n REST API jest od wielu lat najpopularniejszym sposobem pobierania danych z serwera, ale ma kilka wad, z kt\u00f3rymi pr\u00f3bowali sobie poradzi\u0107 tw\u00f3rcy j\u0119zyka GraphQL. Jedn\u0105 z nich jest niska elastyczno\u015b\u0107 narz\u0119dzia w momencie, kiedy zmieniaj\u0105 si\u0119 wymagania klienta. Trzeba w\u00f3wczas zmienia\u0107 API, dopisywa\u0107 nowe lub wersjonowa\u0107, je\u015bli zachodz\u0105 jakie\u015b znacz\u0105ce zmiany.<\/p>\n\n\n\n GraphQL powsta\u0142 po to, aby poradzi\u0107 sobie z potrzeb\u0105 bardziej efektywnej wsp\u00f3\u0142pracy<\/strong> mi\u0119dzy klientem i serwerem. <\/p>\n\n\n\n \u017beby zobrazowa\u0107 r\u00f3\u017cnic\u0119 mi\u0119dzy REST API a GraphQL, sp\u00f3jrzmy na kr\u00f3tki przyk\u0142ad. Niech to b\u0119dzie strona u\u017cytkownika na Facebooku, gdzie potrzebujemy wy\u015bwietli\u0107:<\/p>\n\n\n\n \u017beby otrzyma\u0107 wy\u017cej opisany zestaw danych, serwer musia\u0142by udost\u0119pnia\u0107 3 r\u00f3\u017cne endpointy:<\/p>\n\n\n\n Oczywi\u015bcie, mo\u017cna zaprojektowa\u0107 API w taki spos\u00f3b, aby odpowiada\u0142o wymaganiom tej konkretnej podstrony, ale zwykle si\u0119 tego nie praktykuje. Je\u015bli API mia\u0142oby by\u0107 dostosowywane za ka\u017cdym razem, kiedy zmieni si\u0119 design aplikacji lub wymagania klienta, trwa\u0142oby to d\u0142ugo i ogranicza\u0142o szybko\u015b\u0107 dokonywania zmian w aplikacji. <\/strong><\/p>\n\n\n\n Aby uzyska\u0107 ten sam efekt z u\u017cyciem GraphQL, wystarczy odwo\u0142a\u0107 si\u0119 tylko do jednego endpointa<\/strong>, kt\u00f3ry mo\u017cna odpyta\u0107 o wszystko, co serwer mo\u017ce zwr\u00f3ci\u0107. <\/p>\n\n\n\n W praktyce wygl\u0105da to tak, \u017ce klient wysy\u0142a request za pomoc\u0105 metody POST, w kt\u00f3rego body znajduje si\u0119 zapytanie odzwierciedlaj\u0105ce zestaw danych, jaki ma by\u0107 zwr\u00f3cony z serwera. Pytaj\u0105c o dane usera o konkretnym ID, mo\u017cna ograniczy\u0107 odbierane dane do imienia i nazwiska, jednocze\u015bnie w tym samym zapytaniu wyci\u0105gaj\u0105c posty i 3 ostatnio dodanych followers\u00f3w. <\/p>\n\n\n\n Kiedy serwer otrzymuje takie zapytanie, procesuje je i wyci\u0105ga z bazy tylko te dane, kt\u00f3re zosta\u0142y sprecyzowane w zapytaniu, a nast\u0119pnie zwraca je do klienta w postaci JSON-a.<\/p>\n\n\n\n Problemy, z jakimi rozprawia si\u0119 GraphQL, to:<\/p>\n\n\n\n I zn\u00f3w \u2013 w REST API mo\u017cna oczywi\u015bcie stworzy\u0107 endpoint, kt\u00f3ry zwr\u00f3ci dok\u0142adnie taki zestaw danych, jaki jest nam potrzebny i cz\u0119sto si\u0119 tak robi. Wad\u0105 takiego rozwi\u0105zania<\/strong> jest niemo\u017cno\u015b\u0107 dokonywania szybkich zmian na frontendzie. Zawsze potrzebna jest praca osoby z backendu, kt\u00f3ra poprawi, zmieni API, je\u015bli pojawi si\u0119 potrzeba nowego zestawu danych np.: do nowego widoku.<\/p>\n\n\n\n W GraphQL ten problem nie istnieje<\/strong>. Zmiany na frontendzie mog\u0105 by\u0107 zrobione bez konieczno\u015bci jakiegokolwiek ingerowania w backend.<\/p>\n\n\n\n Kolejn\u0105 zalet\u0105 GraphQL jest to, \u017ce ka\u017cdy request dok\u0142adnie okre\u015bla<\/strong>, jakich danych potrzebuje. Mo\u017cemy te requesty monitorowa\u0107 i np.: stwierdzi\u0107, kt\u00f3re dane nie s\u0105 u\u017cywane przez \u017cadnego klienta lub s\u0105 u\u017cywane sporadycznie i mo\u017cna je okre\u015bli\u0107 jako deprecated. <\/p>\n\n\n\n Nast\u0119pna przewaga nad REST API to u\u017cycie silnego typowania danych<\/strong>. Wszystkie typy, kt\u00f3re s\u0105 widoczne w API, s\u0105 zapisane w schemacie danych przy u\u017cyciu tzw. schema definition language. Po ustaleniu schematu developerzy frontendu mog\u0105 ju\u017c mockowa\u0107 dane i nie ma potrzeby dalszej komunikacji mi\u0119dzy nimi a osobami tworz\u0105cymi backend.<\/p>\n\n\n\n Tworzone po stronie serwera GraphQL Schema to najwa\u017cniejsza cz\u0119\u015b\u0107 pracy z GraphQL API, cz\u0119sto nazywana kontraktem mi\u0119dzy klientem i serwerem. Opisuje typy danych oraz mo\u017cliwo\u015bci API \u2013 to \u201ejak i co\u201d klient mo\u017ce uzyska\u0107 od serwera.<\/p>\n\n\n\n GraphQL ma sw\u00f3j w\u0142asny syntax do definiowania schematu API i jest to Schema Definition Language.<\/p>\n\n\n W powy\u017cszym przyk\u0142adzie wida\u0107 definicj\u0119 dw\u00f3ch prostych typ\u00f3w: Opr\u00f3cz typ\u00f3w danych, osoba tworz\u0105ca serwer GraphQL musi zawsze doda\u0107 i opisa\u0107 typy Pracuj\u0105c z REST API, dane pobierane s\u0105 z konkretnych endpoint\u00f3w, z kt\u00f3rych ka\u017cdy ma z g\u00f3ry zdefiniowan\u0105 struktur\u0119 danych, jak\u0105 zwraca. Czyli ju\u017c na poziomie URL do API okre\u015blone jest, co zostanie zwr\u00f3cone. <\/p>\n\n\n\n W GraphQL podej\u015bcie jest zupe\u0142nie inne. Serwer GraphQL wystawia nam tylko jeden endpoint, w kt\u00f3rym nie ma z g\u00f3ry okre\u015blonej struktury zwracanych danych.<\/p>\n\n\n Do tworzenia, edycji lub usuwania danych GraphQL wykorzystuje tzw. mutacje. Struktura mutacji jest bardzo podobna do query.<\/p>\n\n\n Znowu nale\u017cy u\u017cy\u0107 pola root \u2013 tutaj Trzeci typ zapyta\u0144 to subscription, czyli nas\u0142uchiwanie na zmiany. Subskrypcja u\u017cywana jest do po\u0142\u0105czenia z serwerem w czasie rzeczywistym, tak, \u017ceby aplikacja by\u0142a od razu informowana np. o utworzeniu nowego rekordu.<\/p>\n\n\n Kiedy klient subskrybuje si\u0119 na event, wtedy inicjalizuje i utrzymuje sta\u0142e po\u0142\u0105czenie z serwerem. Zatem, kiedy dany event si\u0119 wydarzy, serwer wypycha dane do klienta.<\/p>\n\n\n\n Kiedy do serwera GraphQL trafia zapytanie, jest ono przechwytywane przez resolvery, czyli funkcje dostarczaj\u0105ce dane.<\/strong> <\/p>\n\n\n\n W implementacji serwera ka\u017cde z p\u00f3l odwo\u0142uje si\u0119 do dedykowanego resolvera. Oznacza to, \u017ce ka\u017cdy z typ\u00f3w zawartych w schema ma zdefiniowane pola, kt\u00f3re nale\u017cy obs\u0142u\u017cy\u0107 za pomoc\u0105 resolver\u00f3w. Resolver zawiera typy odzwierciedlaj\u0105ce schema i pod ka\u017cdy klucz z danego typu tworzy funkcj\u0119, kt\u00f3ra b\u0119dzie zwraca\u0142a dane dla tego typu. <\/p>\n\n\n\n Serwery GraphQL maj\u0105 pewne resolvery domy\u015blne. Potrafi\u0105 obs\u0142ugiwa\u0107 r\u00f3\u017cne typy danych takie jak stringi, liczby, obiekty i tablice.<\/p>\n\n\n Funkcja resolvera przyjmuje 4 argumenty ( \n Zwi\u0119ksz zysk i poszerzaj grono zadowolonych klient\u00f3w dzi\u0119ki naszym us\u0142ugom in\u017cynierii oprogramowania, e-commerce, mobile i digital customer experience.\n <\/p>\n \n Oferta Digital<\/span>\n <\/a>\n <\/div>\n<\/div>\n\n\n\n Okazuje si\u0119, \u017ce te dwie metody nie musz\u0105 dzia\u0142a\u0107 osobno i mog\u0105 z powodzeniem ze sob\u0105 wsp\u00f3\u0142istnie\u0107<\/strong>. Wiele system\u00f3w dzia\u0142a tak, \u017ce po stronie klienta np.: na urz\u0105dzeniu IoT, aplikacji mobilnej czy webowej, dzia\u0142a GraphQL i tu konstruowane s\u0105 zapytania GraphQL. Dane te s\u0105 przesy\u0142ane do resolvera na serwerze GraphQL, a resolver odpytuje np.: mikroserwisy ju\u017c z u\u017cyciem REST API.<\/p>\n\n\n\n GraphQL lepiej sprawdzi si\u0119<\/strong> w aplikacji, kt\u00f3ra potrzebuje r\u00f3\u017cnych danych na ka\u017cdej ze stron. Natomiast, je\u015bli s\u0105 to du\u017ce ilo\u015bci danych, lepiej u\u017cy\u0107 REST API<\/strong>, poniewa\u017c zbyt skomplikowane zapytania do GraphQL mog\u0105 si\u0119 okaza\u0107 wolniejsze ni\u017c zapytania do kilku REST-owych endpoint\u00f3w. Nie podlega te\u017c dyskusji fakt, \u017ce REST API buduje si\u0119 szybciej i \u0142atwiej<\/strong>, dlatego dla ma\u0142ych aplikacji nie ma sensu budowa\u0107 serwera GraphQL.<\/p>\n\n\n\n Zdarzaj\u0105 si\u0119 r\u00f3wnie\u017c konkretne przypadki, w kt\u00f3rych konieczne b\u0119dzie zrezygnowanie z GraphQL<\/strong>. Ograniczeniem jest fakt, \u017ce GraphQL nie poradzi sobie z zagnie\u017cd\u017ceniem zapyta\u0144, kt\u00f3rych g\u0142\u0119boko\u015bci nie mo\u017cna okre\u015bli\u0107 np.: menu i podmenu, gdzie ka\u017cdy element podmenu mo\u017ce mie\u0107 kolejne podmenu. Klient nie jest w stanie stwierdzi\u0107, jaki jest poziom zagnie\u017cd\u017ce\u0144, dlatego nie mo\u017ce jednoznacznie okre\u015bli\u0107 budowy zapytania.<\/p>\n\n\n\n Ci\u0119\u017cko jednoznacznie okre\u015bli\u0107, czy GraphQL jest lepszy i czy mo\u017ce wyprze\u0107 REST API, jednak pewne jest<\/strong>, \u017ce obie technologie mog\u0105 z powodzeniem wsp\u00f3\u0142gra\u0107 i wsp\u00f3\u0142pracowa\u0107 ze sob\u0105, a ka\u017cda z nich mo\u017ce sprawdzi\u0107 si\u0119 lepiej w konkretnych przypadkach u\u017cycia.<\/p>\n\n\n\n ***<\/p>\n\n\n\n Je\u015bli interesuje Was temat REST API, zach\u0119camy do zerkni\u0119cia r\u00f3wnie\u017c do innych artyku\u0142\u00f3w naszych ekspert\u00f3w. <\/a><\/p>\n\n\nGraphQL vs REST API<\/strong><\/h2>\n\n\n\n
\n
Jakby to wygl\u0105da\u0142o z u\u017cyciem REST API?<\/strong><\/h2>\n\n\n\n
\n
\/users\/id<\/code>, sk\u0105d mo\u017cemy otrzyma\u0107 dane u\u017cytkownika. Zwykle takie API zwr\u00f3ci nam wszystkie dane dotycz\u0105ce danej osoby, czyli du\u017co wi\u0119cej informacji ni\u017c jest wymagane.<\/li>\n\n\n\n\/users\/id\/posts<\/code>. Je\u015bli takie API nie oferuje limitowania danych, zwr\u00f3cona zostanie lista wszystkich post\u00f3w, czyli zn\u00f3w za du\u017co danych wzgl\u0119dem tego, co przewiduje projekt.<\/li>\n\n\n\n\/users\/id\/followers<\/code> \u2013 po raz kolejny zderzamy si\u0119 z tym, \u017ce dostajemy mas\u0119 danych, kt\u00f3re s\u0105 zb\u0119dne, czyli list\u0119 wszystkich followers\u00f3w danego u\u017cytkownika.<\/li>\n<\/ul>\n\n\n\n![\"Przyk\u0142adowe](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/07\/Przechwytywanie.jpg\")
<\/a>Jak zrobi\u0107 to samo z u\u017cyciem GraphQL?<\/strong><\/h2>\n\n\n\n
<\/a>Przewaga GraphQL nad REST API<\/strong><\/h2>\n\n\n\n
\n
Serwer GraphQL<\/strong><\/h2>\n\n\n\n
Schema<\/strong><\/h3>\n\n\n\n
\ntype Post {\n id: ID!\n title: String!\n author: User!\n}\n\ntype User {\n id: ID!\n name: String!\n age: Int!\n posts: [Post!]!\n followers: [User]\n photoUrl: String!\n}\n<\/pre><\/div>\n\n\nUser i Post<\/code><\/strong> oraz relacji jeden do wielu mi\u0119dzy typami. Typ User<\/code> ma odwo\u0142anie do post\u00f3w \u2013 ka\u017cda osoba mo\u017ce mie\u0107 do siebie przypisan\u0105 list\u0119 post\u00f3w. W drug\u0105 stron\u0119 \u2013 Post<\/code> mo\u017ce mie\u0107 jednego autora. Wykrzyknik umieszczony za typem pola oznacza, \u017ce warto\u015b\u0107 jest wymagana i nie mo\u017ce by\u0107 nullem. <\/p>\n\n\n\nroot<\/code> czyli Query, Mutation i Subscription<\/code>.<\/p>\n\n\n\nQuery<\/strong><\/h3>\n\n\n\n
\ntype Query {\n allUsers(first: Int): [User!]\n user(id: ID!): User\n allPosts: [Post!]\n post(id: ID!): Post\n}\n<\/pre><\/div>\n\n\nMutation<\/strong><\/h3>\n\n\n\n
\ntype Mutation {\n createUser(name: String!, age: Int!): User!\n updateUser(id: ID!, name: String!, age: String!): User!\n deleteUser(id: ID!): User!\n createPost(title: String!): Post!\n updatePost(id: ID!, title: String!): Post!\n deletePost(id: ID!): Post!\n}\n<\/pre><\/div>\n\n\ncreateUser<\/code>. Pole createUser<\/code> otrzymuje 2 argumenty: name<\/code> oraz age<\/code> <\/strong>i zwraca obiekt nowo utworzonej warto\u015bci typu User<\/code>. R\u00f3wnie dobrze createUser<\/code> mog\u0142oby zwr\u00f3ci\u0107 tylko identyfikator nowo utworzonego rekordu lub jaki\u015b status i dane.<\/p>\n\n\n\nSubscription<\/strong><\/h3>\n\n\n\n
\ntype Subscription {\n newUser: User!\n updatedUser: User!\n deletedUser: User!\n newPost: Post!\n updatedPost: Post!\n deletedPost: Post!\n}\n<\/pre><\/div>\n\n\nResolvers<\/strong><\/h3>\n\n\n\n
\nconst resolvers = {\n Query: {\n allUsers: () => usersList,\n user: (parent, args, context, info) => usersList.find((user) => user.id == args.id),\n allPosts: () => postsList,\n post: (parent, args, context, info) => usersList.find((post) => post.id == args.id),\n },\n Mutation: {\n createUser: (parent, args, context, info) => {\n const newUser = {\n id: usersList.length + 1,\n name: args.name,\n age: args.age,\n };\n usersList.push(newUser);\n return newUser;\n },\n \u2026\n },\n Post: {\n title: (parent, args, context, info) => parent.title,\n author: (parent, args, context, info) => usersList.find((user) => user.id == parent.author_id),\n },\n User: {\n \u2026,\n posts: (parent, args, context, info) => postsList.filter((post) => post.author_id == parent.id),\n },\n};\n<\/pre><\/div>\n\n\nparent, args, context i info<\/code>), o kt\u00f3rych wi\u0119cej poni\u017cej:<\/p>\n\n\n\n\n
parent<\/code> \u2013 to obiekt rodzica, czyli obiekt, kt\u00f3ry by\u0142 dostarczony poziom wy\u017cej np.: dla resolvera author<\/code> w polu parent<\/code> przekazany b\u0119dzie Post<\/code>,<\/li>\n\n\n\nargs<\/code> \u2013 to argumenty przekazane do resolvera, np.: szukane ID,<\/li>\n\n\n\n\n <\/picture>\n Digital<\/h2>\n <\/div>\n
Kiedy GraphQL, a kiedy REST API?<\/strong><\/h2>\n\n\n\n