GraphQL – Zmieniając i poprawiając sposób, w jaki aplikacje komunikują się

Nie minie dużo czasu, zanim następne pokolenie będzie kupowało kryptowaluty i sprawdzało saldo swoich jednostek zaufania w lobbie Fortnite między grami. To będzie możliwe dzięki wielu postępom technologicznym.

Jednym z nich, o którym będziemy dzisiaj dyskutować, jest sposób, w jaki dane są przenoszone (odczytywane, aktualizowane, dodawane/usuwanie) między aplikacjami i firmami, które je posiadają. Interfejsy programistyczne aplikacji (API) to architektura, która definiuje tę komunikację danych, a gdy te standardy się rozwijały, wymagania dotyczące przetwarzania i przechowywania danych stały się mniej uciążliwe.

Liderem w tej dziedzinie, jeśli chodzi o “lekki” zużycie zasobów, jest GraphQL, otwarty język zapytań i manipulacji danymi. Podstawą jego ekosystemu jest specyfikacja i zbiór narzędzi stworzonych wokół niego.

Nie jest to nowość – czas mija szybko. Facebook opracował go w 2012 roku i używał go tylko wewnętrznie do rozwoju aplikacji mobilnych. W 2015 roku został “otwarty” i obecnie jest nadzorowany przez Fundację GraphQL (https://graphql.org/foundation/), która nadzoruje jego dalszy rozwój.

Dlaczego więc piszę o tym teraz? Typowy plan przyjęcia technologii będzie obejmował następujące etapy: 1) hobbystów/projekty osobiste, 2) wdrożenie w wielu językach, 3) wdrożenie w start-upach i małych firmach, 4) średnie firmy i użycie w rozwoju produktów, 5) duże korporacje i giganci technologiczni.

GraphQL osiągnął poziom 5. Obecnie jest używany przez GitHub, Pinterest, Shopify, Microsoft, aby wymienić tylko kilka, i najnowszy, od marca 2022 roku, Salesforce.

Poszukując sposobu na pobranie danych w sposób bardziej wydajny z Salesforce, natknąłem się na ich dokumentację GraphQL i zacząłem czytać i szukać sposobów na jego wdrożenie.

Jak się różni od tradycyjnego API REST?

• Jedną z głównych zalet jest to, że z GraphQL możesz wysyłać zapytania i otrzymywać tylko te dane, które są potrzebne. Jeśli chcesz tylko dwa pola związane z określoną sprawą klienta, to właśnie to otrzymujesz. Tradycyjne API REST zwróciłoby wszystkie pola związane ze sprawą. To mogłoby być 100+ pól. Teraz musisz coś zrobić z tymi danymi, których nie chciałeś od samego początku. Nazywa się to przesadnym pobieraniem danych (niedopobieranie danych jest również problemem).
• Powyższe sprawia, że GraphQL jest szybszy niż inne metody API przy zwracaniu danych.
• GraphQL to język silnie typowany, co oznacza, że błędy kodu są wykrywane przed uruchomieniem programu, a nie podczas jego wykonywania.
• Wokół GraphQL został stworzony zestaw narzędzi, co sprawia, że jest bardzo przyjazny dla programistów.
• GraphQL ma jeden punkt końcowy, w przeciwieństwie do API REST, które ma wiele punktów końcowych. To oznacza, że wszystkie dane można pobrać w jednym żądaniu.

Dwa oblicza medalu: żądający (klient) i dostawca (host GraphQL)

Dotychczas patrzyłem na GraphQL z perspektywy “żądania” danych. Gdzie firma, taka jak Salesforce lub Microsoft, ustawia API GraphQL, które można wykorzystać do zapytań i manipulacji danymi (odczytu, aktualizacji, dodawania).

Na przykład, jeśli chcielibyśmy uwzględnić dane z Salesforce dotyczące spraw klientów w portalu klienta, najbardziej wydajnym sposobem byłoby wysłanie zapytania GraphQL do serwera Salesforce GraphQL. Otrzymasz dokładnie te dane, których potrzebujesz, bez nadmiaru lub niedoboru danych, a w rezultacie nie będą wymagane dodatkowe przetwarzanie ani przechowywanie danych.

Drugą stroną medalu jest organizacja, która ustawia architekturę GraphQL, aby klienci mieli wydajny sposób dostępu do danych, których potrzebują.

Budując API GraphQL, organizacja tworzy model, który integruje wszystkie systemy w jeden model. To ujednolica te systemy i po zakończeniu pracy usuwa złożoność podstawowych systemów. Po zakończeniu pracy zapytania o dane stają się bezproblemowe za pośrednictwem API.

Gdy porównuję aplikacje lub dostawców, patrzę na to, jakie funkcje oferują mi, aby odzyskać moje dane. Nie chcę musieć im wysyłać e-maili ani polegać na sztywnych, predefiniowanych raportach. Chcę móc “wpiąć się” w moje dane, zapytując je w elastyczny, terminowy sposób. Jeśli chodzi o dwa aplikacje/dostawców, które są podobne w innych punktach porównania, a jeden oferuje API REST lub GraphQL, zdecydowanie wybieram ten z API.