GraphQL z Flutter — jak używać, by zwiększyć optymalizację bazy danych?

Na ekranie smartfona można wyświetlić w czytelny i przyjazny sposób znacznie mniej informacji niż w przypadku monitora komputerowego. Z tego też powodu, aby zoptymalizować płynność działania aplikacji mobilnych, należy się przede wszystkim upewnić czy wysyłane za pośrednictwem API zapytania pobierają tylko i wyłącznie niezbędne dane.

Tworzone współcześnie wieloplatformowe aplikacje współdzielą ze sobą najczęściej bazę danych, ponieważ w ten właśnie sposób da się stosunkowo łatwo uniknąć wielu niepotrzebnych kosztów. Dzięki współdzielonej bazie danych można zabezpieczyć się przed scenariuszem, w którym każdy potencjalnie wykryty błąd trzeba naprawiać osobno dla każdej platformy. Pomimo że w teorii REST jest w stanie przynajmniej częściowo rozwiązać ten problem, to w praktyce nie zawsze tak jest. Na szczęście na skutek zmagań z analogicznymi trudnościami developerzy z Facebooka opracowali własne rozwiązanie o nazwie GraphQL, które następnie rozpowszechniło się dzięki fundacji Linuxa.

Czym dokładnie jest GraphQL i dlaczego tak wiele osób nazywa go następcą RESTa? Jakie koncepcje leżą u podstaw GraphQL? W jaki sposób GraphQL pomaga w optymalizacji wieloplatformowych aplikacji? Na wszystkie te pytania postaramy się odpowiedzieć w poniższym poradniku.

Co to jest GraphQL i czym odróżnia się od REST?

Opublikowany w 2015 roku przez developerów z Facebooka (obecnie Meta) GraphQL to jeden z najpopularniejszych otwartych języków zapytań (ang. Query Language). Warto podkreślić tu jednak, iż od 2018 roku odpowiedzialność za dalszy rozwój GraphQL przejęła sławetna organizacja non-profit Linux Foundation. W odpowiedzi na przesyłane za pośrednictwem API i GraphQL zapytania najczęściej zwracane są dane w formie dokumentu w formacie JSON. Jedną z największych zalet GraphQL jest to, iż w porównaniu do REST zapewnia on znacznie większą elastyczność i precyzję. Ponadto w przeciwieństwie do REST GraphQL do obsługi wymiany danych wykorzystuje tylko i wyłącznie jeden endpoint.

Dlaczego GraphQL określany jest mianem następcy RESTa?

Nieustannie rozwijany w charakterze projektu typu open-source GraphQL najbardziej przydaje się w przypadku wieloplatformowych aplikacji, ponieważ w tym właśnie scenariuszu niemalże zawsze zaczynają się pierwsze problemy z RESTem. Jeśli aplikacja mobilna wyświetla mniej danych niż desktopowa, to nie powinno się niepotrzebnie pobierać w wersji mobilnej nadmiaru informacji, gdyż spowolni to jej działanie. Pobieranie danych za pośrednictwem API i GraphQL jest dużo łatwiejsze od REST API ze względu na to, iż nie trzeba tworzyć dodatkowych zapytań ani endpointów. Mając na uwadze, iż twórcy GraphQL od początku starają się rozwiązać problemy znane każdemu, kto próbował rozwijać wieloplatformową aplikacje w standardzie REST API, łatwo zrozumieć można, dlaczego język ten w pełni zasłużył na miano następcy RESTa.

Podstawy GraphQL – najważniejsze koncepcje i pojęcia

Zanim na podstawie przykładowych zapytań zobrazujemy przewagę, jaką GraphQL zapewnia nad RESTem, musimy wpierw, chociaż częściowo wyjaśnić podstawy GraphQL. Warto wspomnieć tu również, iż szczegółowa specyfikacja i dokumentacja GraphQL jest w pełni dostępna w języku angielskim na stronie fundacji GraphQL. Do najważniejszych koncepcji w GraphQL zaliczyć trzeba następujące 3 terminy:

1. Typ Query

Komunikacja danych w GraphQL bazuje na zapytaniach (ang. Queries), które to definiowane są właśnie przy pomocy słowa kluczowego query oraz dodatkowych parametrów (np. nazw poszczególnych właściwości zasobów). Należy podkreślić tu również, iż każde zapytanie w GraphQL przechodzi przez 3 fazy (parsowania, walidacji i wykonania). Finalnie, obiekt JSON, który otrzymujemy w odpowiedzi na prawidłowe zapytanie, będzie wypełniony danymi w dokładnie takiej samej strukturze jak w zapytaniu.

2. Resolver

Jako że GraphQL nie potrafi sam określić, gdzie dokładnie znajdują się dane, o które pytamy, to trzeba mu to wyjaśnić przy pomocy tzw. resolverów. Innymi słowy, jest to zbiór funkcji odpowiedzialnych za generowanie odpowiedzi na przesyłane za pośrednictwem API zapytania. Resolver może zwracać zarówno obiekty, obietnice, jak i też wartości skalarne (np. Int, Float, String, Boolean, ID itp.).

3. Schema

W GraphQL zawsze trzeba zaprojektować schemat (ang. Schema), który będzie definiował, w jaki sposób przebiega komunikacja z serwerem API. Definicje te określa się zazwyczaj przy pomocy języka SDL (ang. Schema Definition Language) lub IDL (Interface Definition Language). GraphQL można połączyć z dowolnym językiem programowania (np. Dart, JavaScript, Java, Ruby, Scala itd.), ale trzeba pamiętać tu, iż jest on klasyfikowany jako język silnie typowany. Innymi słowy, każda definicja musi mieć dokładnie określony typ. Podstawowym komponentem schematu, który reprezentuje obiekt wraz z jego właściwościami, są typy obiektowe (ang. Object Types). W GraphQL wyróżnić można także typy skalarne oraz typy wyższego rzędu (ang. Root Types), takie jak np. typ Query, Mutation albo Subscription. Ostatnie trzy wspomniane typy odpowiadają kolejno za akcje takie jak pobieranie, modyfikowanie czy obserwowanie.

Jak wygodnie budować zapytania API w GraphQL? 

Jedną z wielu zalet GraphQL jest to, iż zarówno z poziomu przeglądarki internetowej, jak i dedykowanego IDE (np. GraphQL Playground albo GraphiQL) można korzystać z niezwykle praktycznych podpowiedzi. Jeżeli w trakcie tworzenia zapytania API wciśniemy jednocześnie klawisz control i spację, GraphQL wygeneruje nam automatycznie listę dostępnych funkcji oraz obiektów. Dzięki tej niezmiernie wygodnej funkcjonalności tworzenie precyzyjnych zapytań staje się dużo łatwiejsze i szybsze. Warto wspomnieć tu także, iż GraphQL pozwala na to, by w jednym zapytaniu pobierać różne rodzaje danych, a jeśli nie znamy parametrów poszczególnych obiektów, to dzięki wspomnianemu wyżej skrótowi automatycznie wygeneruje się lista dostępnych właściwości. Bardziej wymagających użytkowników ucieszy zaś z pewnością to, iż w zapytaniach typu Query można dowolnie zagnieżdżać informacje, jeśli tylko pozwala na to struktura danych.

Podsumowanie – w jaki sposób GraphQL pomaga w zwiększeniu optymalizacji aplikacji opracowanych we Flutter?

W przypadku wieloplatformowych aplikacji, które powstają na bazie Fluttera, zamiast tracić czas na tworzenie większej liczby endpointów w standardzie REST, zdecydowanie bardziej opłaca się postawić na GraphQL, gdyż w każdym zapytaniu wykorzystuje on w trakcie komunikacji tylko jeden endpoint. Zarówno w przypadku mobilnych, jak i też desktopowych wersji aplikacji nie powinno się za pośrednictwem API pobierać zbędnych danych, ponieważ może to odczuwalnie pogorszyć wydajność po stronie klienta. Problem z długim czasem wczytywania danych w odpowiedzi na wygenerowane przez użytkownika zapytania jest dużo bardziej dotkliwy na urządzeniach mobilnych (np. smartfonach, laptopach oraz tabletach). Niezoptymalizowane zapytania API (np. pobieranie 1000 rekordów, aby wyświetlić 1) pochłaniają niepotrzebnie więcej transferu, pamięci i mocy obliczeniowej, a to zużywa dodatkowo więcej energii. Z tych też powodów, aby zoptymalizować płynność komunikacji dla aplikacji wieloplatformowych we Fluttter, zamiast REST znacznie rozsądniej jest wykorzystać GraphQL.