Przykłady użycia graphQl w Magento 2.3

1. GraphQl w Magento 2.3 -
wprowadzenie, porównanie
i customowe endpointy
Anna Kurnat
a.kurnat@wearevirtua.com

2. 1. Ewolucja API w Magento
2. REST - rozwiązania problemów
3. GraphQl
a. Czym jest?
b. Zalety i wady
c. Budowa graphQl
d. GraphQl vs REST
e. Customowe grafy

3. Ewolucja API w Magento

4. Ewolucja API w Magento
● każda metoda ma swój endpoint
● ACL per endpoint
● sztywna struktura zapytania i otrzymywanych danych
● pobieranie za małej lub za dużej ilości danych
○ jeden request może pobrać dane, które nie są potrzebne
○ wiele requestów koniecznych, aby pobrać konieczne dane
● rozwój frontendu uzależniony od zmian w backendzie
● w Magento 2 cała funkcjonalność dostępna w UI jest pokryta
RESTem

5. Ewolucja API w Magento
● jeden endpoint
● łączone requesty
● elastyczny schemat danych
● szybszy development
● niezależny rozwój frontu od backendu
● brak konieczności tworzenia service kontraktów + możliwość
wykorzystania istniejących

6. REST API

7. REST
SYNCHRONICZNE
ENDPOINTY
ASYNCHRONICZNE
ENDPOINTY
ZWYKŁE BULK

8. Service Contract
- uniezależnienie frontu i backendu

9. Lepszy rozdział funkcjonalności
Minimalizacja konfliktów między modułami
Ukryta logika biznesowa z zachowaniem
spójności danych
Lepsza dokumentacja
Trudniejsza implementacja małych
modyfikacji, wymagająca więcej ilości zmian

10. Service contracts - zestaw
interfejsów wykorzystywanych do
zdefiniowania API
API - zestaw interfejsów, które moduł
udostępnia innym modułom, aby
mogły korzystać z ich implementacji.

11. Filtracja
- pobieranie tylko potrzebnych danych

12. ?fields=<field_or_object1>,
<field_or_object2>
Wspierane w:
GET
POST
PUT
Można używać przez
searchCriteria.
Niedostępne na SOAP,
ponieważ SOAP nie
zezwala na częściowe
responsy.

14. logika ->OR

15. logika ->AND

16. logika ->AND OR

17. Bulk API
- wykonywanie jednego requestu

19. Customowe endpointy
- rozszerzanie funkcjonalności

20. Dodanie Interfejsów

21. Dodanie repository

22. Dodanie konfiguracji

24. GraphQl

25. Czym jest graphQl?
● graphQL - język zapytań dla API
● nowy standard, definiuje jak klient może pobierać dane z servera
● stworzony przez Facebook
● rozwijany jako open source
● w Magento dodany obok SOAP i REST
● cel:
○ optymalizacja zapytań = szybszy front
○ rozdzielenie developmentu frontendu od backendu
● https://graphql.org/

26. Czym jest graphQl?
GraphQL - język zapytań dla APIs
● Aplikacje pobierają dane z servera, gdzie te dane są przechowywane
w bazie. Za pobieranie danych, które odpowiadałyby
zapotrzebowaniom aplikacji odpowiada API, ono też tworzy w tym
celu interfejs.
● GraphQL często jest mylony z technologią bazodanową. Jednak
GraphQL jest językiem zapytań dla APIs - nie baz danych. Dzięki temu
nie jest zależny od rodzaju ani rozplanowania bazy danych i możemy,
go efektywnie używać w każdym kontekście, gdzie mamy API.
APIQUERY DATA

27. Zalety:
1. silne typowanie schematów
○ w innych API często brakuje informacji jakie dane są przyjmowane i zwracane
○ brak określonych kontraktów (Magento tworzyło dodatkowo Service Contracts i Data
Contracts dla REST)
○ podpowiedzi w edytorze - automatyczne generowanie dokumentacji
2. ACL per obiekt
3. nie pobieranie za dużej, ani za małej ilości danych
○ pobierane są akurat te dane, które będą potrzebne
○ jeden request, szybsza praca
○ użytkownik określa jak ma być zbudowana odpowiedź z servera
4. szybszy rozwój UI produktu
○ realtime, caching, szybkie zmiany UI (nie trzeba czekać na update endpointów)
○ gotowe biblioteki - Apollo, Relay, Urql
5. łączenie wielu schematów
○ umożliwia zachowanie modularności
6. szeroki ekosystem open-source i wsparcie community
○ przykłady i wsparcie
○ toolsy

28. Wady:
200 jest zwracane przy każdej odpowiedzi
sami musimy szukać błędów - dobry exception handling

29. Elementy
SCHEMA MUTATIONSQUERIES SUBSCRIPTIONS

30. Schema Definition Language (SDL)

31. Queries
REQUEST
RESPONSE

32. Queries
REQUEST
RESPONSE

33. Zagnieżdżanie queries
REQUEST
RESPONSE

34. Zagnieżdżanie queries
REQUEST
RESPONSE

35. Mutacje

36. Subskrypcje
Subskrypcje umożliwiają aplikacji połączenie z serverem w czasie rzeczywistym, aby mogła być
informowana o ważnych eventach na bieżąco.
Gdy klient subskrybuje się do eventu, graphQl zachowa między nimi stałe połączenie
klient-server. Gdy dany event się wydarzy, server wypycha powiązane dane do klienta.
Subskrypcje w przeciwieństwie do queries nie są w cyklu request-response, tylko streamuja
dane z servera do klienta.

37. Całość

38. Jak to działa?

39. Jak to działa?

40. Jak to działa?

41. Uwierzytelnianie
graphQl
context

42. GraphQl vs REST

43. REST

44. graphQl

45. Queries
REST API:
● dane są ładowane z określonego endpointu.
● każdy endpoint ma ściśle określoną strukturę wg. której zwraca informacje
● wymagane dane wejściowe są zakodowane w URLu, z którym klient się łączy
GraphQL:
● zamiast wielu endpointów jest jeden
● zwracana struktura danych jest bardzo elastyczna, klient decyduje jakie dane są mu
aktualnie potrzebne
● klient musi wysłać więcej informacji o tym jakich danych potrzebuje pod postacią query

46. Resources
VS

47. Url vs schema
VS

48. Użycie w Magento 2

49. Co jest juz zrobione w 2.3?
1. CMS Page
2. CMS Block
3. Store Config
4. Customer
5. Product
6. Category
7. URL Resolver
8. Custom Attribute Metadata

50. Dostępne moduły
● module-bundle-graph-ql
● module-catalog-graph-ql
● module-catalog-inventory-graph-ql
● module-catalog-url-rewrite-graph-ql
● module-cms-graph-ql
● module-cms-url-rewrite-graph-ql
● module-configurable-product-graph-ql
● module-customer-graph-ql
● module-downloadable-graph-ql
● module-eav-graph-ql
● module-grouped-product-graph-ql
● module-quote-graph-ql
● module-store-graph-ql
● module-swatches-graph-ql
● module-tax-graph-ql
● module-wee-graph-ql

51. Plany na przyszłość?
1. Mutacje do checkoutu i płatności
2. API dla storefront’u dla checkoutu, orderów, my account
3. Poprawki w dotychczasowych endpointach:
a. cachowanie
b. wydajność zapytań

52. Gdzie znajdziemy graphQl?
DOMAIN
LAYER
INDEX
TABLES +
INDEXES

53. Apollo server

54. Resolver

55. Resolver
Każde pole w schema GraphQL posiada resolver.
W podstawowej formie GraphQL ma 1 resolver per pole w schema. Każdy resolver wie jak
pobierać dane do swojego pola. Query GraphQL to kolekcja pól, więc aby zebrać dane z każdego
z nich, należy odpalić wszystkie resolvery.
STRUKTURAGRAPHQL ZACHOWANIE
schema resolver

56. GraphQl module - CMS
● schema
● resolver
● data provider

57. Schema - CMS

58. Resolver

59. Użycie

60. Użycie

61. Użycie

62. Użycie

63. Schema - catalog

64. Resolver

65. Użycie

66. Mutacje - przykład

67. Customowe grafy

68. Tworzenie modułu

69. Dodawanie schema

70. Dodawanie modelu resolvera

71. Sprawdzenie

72. Które API najlepsze?
TO ZALEŻY…