Czy są jakieś wady GraphQL? [Zamknięte]

Wszystkie artykuły o GraphQL powiedzą ci, jakie to wspaniałe, ale czy są w nim jakieś wady lub wady? Dziękuję Ci.

Niedogodności:

• Musisz się nauczyć, jak skonfigurować GraphQL. Ekosystem wciąż szybko się rozwija, więc musisz nadążyć.
• Musisz wysyłać zapytania od klienta, możesz po prostu wysyłać ciągi znaków, ale jeśli chcesz większego komfortu i buforowania, skorzystasz z biblioteki klienta -> dodatkowy kod w swoim kliencie
• Musisz wcześniej zdefiniować schemat => dodatkowa praca, zanim uzyskasz wyniki
• Musisz mieć punkt końcowy graphql na swoim serwerze => nowe biblioteki , których jeszcze nie znasz
• Zapytania Graphql zajmują więcej bajtów niż zwykłe przechodzenie do punktu końcowego REST
• Serwer musi wykonać więcej przetwarzania, aby przeanalizować zapytanie i zweryfikować parametry

Ale te są więcej niż przeciwstawiane przez te:

• GraphQL nie jest trudny do nauczenia
• Dodatkowy kod to tylko kilka KB
• Definiując schemat, zapobiegniesz późniejszej pracy przy naprawianiu błędów i utrzymywaniu owłosionych ulepszeń
• Wiele osób przechodzi na GraphQL, więc rozwija się bogaty ekosystem z doskonałymi narzędziami
• Używając trwałych zapytań w środowisku produkcyjnym (zastępując zapytania GraphQL po prostu identyfikatorem i parametrami), w rzeczywistości wysyłasz mniej bajtów niż w przypadku REST
• Dodatkowe przetwarzanie dla przychodzących zapytań jest znikome
• Zapewnienie czystego oddzielenia interfejsu API i zaplecza pozwala na znacznie szybszą iterację ulepszeń zaplecza

Znalazłem kilka ważnych obaw dla każdego, kto rozważa użycie GraphQL , a do tej pory główne punkty to:

Zapytanie w nieokreślonej głębokości : GraphQL nie może wykonywać zapytań na nieokreślonej głębokości, więc jeśli masz drzewo i chcesz zwrócić gałąź bez znajomości głębokości, będziesz musiał zrobić trochę paginacji.

Specyficzna struktura odpowiedzi : W GraphQL odpowiedź odpowiada kształtowi zapytania, więc jeśli potrzebujesz odpowiedzieć w bardzo specyficznej strukturze, musisz dodać warstwę transformacji, aby zmienić kształt odpowiedzi.

Pamięć podręczna na poziomie sieci : Ze względu na powszechny sposób używania GraphQL przez HTTP (POST w jednym punkcie końcowym) pamięć podręczna na poziomie sieci staje się trudna. Sposobem na rozwiązanie tego problemu jest użycie trwałych zapytań.

Obsługa przesyłania plików : W specyfikacji GraphQL nie ma nic o przesyłaniu plików, a mutacje nie akceptują plików w argumentach. Aby rozwiązać ten problem, możesz przesłać pliki za pomocą innego rodzaju interfejsów API (takich jak REST) ​​i przekazać adres URL przesłanego pliku do mutacji GraphQL lub wstrzyknąć plik w kontekście wykonania, dzięki czemu będziesz mieć plik wewnątrz funkcji resolvera.

Nieprzewidywalne wykonanie : Naturą GraphQL jest to, że możesz wykonywać zapytania łącząc dowolne pola, ale ta elastyczność nie jest darmowa. Istnieją pewne obawy, które warto znać, takie jak wydajność i zapytania N + 1.

Super Simple APIs : jeśli masz usługę, która udostępnia naprawdę proste API, GraphQL doda tylko dodatkową złożoność, więc prosty REST API może być lepszy.

Ten największy problem, który widzę z GraphQL, tj. Jeśli używasz z relacyjną bazą danych, dotyczy złączeń .

1. Fakt, że możesz zezwolić / zabronić kilku pól, sprawia, że ​​łączenia są nietrywialne (nie proste). Co prowadzi do dodatkowych zapytań.

2. Również zapytania zagnieżdżone w graphql prowadzą do zapytań cyklicznych i mogą spowodować awarię serwera . Należy zachować szczególną ostrożność.

3. Ograniczanie szybkości połączeń staje się trudne, ponieważ teraz użytkownik może uruchamiać wiele zapytań w jednym połączeniu.

WSKAZÓWKA : Użyj dataloadera Facebooka, aby zmniejszyć liczbę zapytań w przypadku javascript / node

Z każdym rokiem jest coraz lepiej, a na razie społeczność GraphQL rośnie, w wyniku czego istnieje znacznie więcej rozwiązań wielu problemów, które zostały wcześniej podkreślone w innych odpowiedziach. Ale żeby przyznać, że firmy wciąż powstrzymują przed wyrzuceniem wszystkich zasobów do GraphQL, chciałbym wymienić kilka problemów i rozwiązań, a następnie nierozwiązane.

• Pamięć podręczna na poziomie sieci - jak powiedział Bruno , to trwałe zapytania i oczywiście możesz buforować na kliencie i nikt nie powstrzyma Cię przed użyciem buforowania na poziomie bazy danych, a nawet Redis. Ale oczywiście, ponieważ GraphQL ma tylko jeden punkt końcowy, a każde zapytanie jest inne - wykonanie tego typu buforowania jest znacznie bardziej skomplikowane niż w przypadku REST.
• Zagnieżdżone zapytania w GraphQL prowadzą do zapytań cyklicznych i mogą spowodować awarię serwera - nie stanowi to już problemu przy szerokiej gamie rozwiązań. Niektóre z nich są wymienione tutaj
• Obchodzenie File Upload - mamy już wiele z rozwiązań dla niej

Ale jest jeszcze kilka przypadków, które można zaliczyć jako wady:

• standardowa nadmierność (mam przez to na myśli, aby utworzyć na przykład nowe zapytanie, musisz zdefiniować schemat, resolver i wewnątrz resolvera, aby wyraźnie powiedzieć GraphQL, jak rozwiązać twoje dane i pola wewnątrz, po stronie klienta utwórz zapytanie z dokładnie polami związanymi z te dane)
• obsługa błędów - muszę powiedzieć, że jest to bardziej związane z porównaniem z REST. Z apollo jest to możliwe,ale jednocześnie jest to dużo bardziej skomplikowane niż w REST
• uwierzytelnianie i autoryzacja - ale jak powiedziałem społeczność rośnie z wyjątkową szybkością i istnieje już kilka z rozwiązań dla tego celu.

Podsumowując, GraphQL to tylko narzędzie do konkretnych celów i na pewno nie jest srebrną kulą dla wszystkich problemów i oczywiście nie zastępuje REST.

Wspaniale jest mieć jeden punkt końcowy i udostępniać wszystkie dane. Poniżej znajdują się punkty, które należy wziąć pod uwagę w przypadku GraphQL:

1. Implementacja pobierania / wysyłania plików staje się trudna (konwersja na ciąg może nie być najlepszą opcją w przypadku dużych plików)
2. Wiele standardowych i schematycznych kodów zarówno na frontend, jak i na zapleczu.
3. Przestrzegaj i obsługuj paginację podaną w specyfikacji GraphQL.
4. Zezwalaj na niestandardową kolejność i priorytetyzację logiki do porządkowania pól. Przykład, jeśli pobieramy dane użytkowników oraz powiązane grupy i role. Użytkownik może sortować dane w wielu miejscach na podstawie nazwy użytkownika, nazwy grupy lub nazwy roli.
5. Uwierzytelnianie i autoryzacja byłyby zależne od struktury zaplecza.
6. Upewnij się, że optymalizacja zaplecza i obsługa bazy danych w celu uruchomienia pojedynczego zapytania dla każdego polecenia graphql może być trudne.

Należy również wziąć pod uwagę Plusy po jego wdrożeniu:

1. Bardzo elastyczny, aby obsługiwać nowe elementy i aktualizować istniejące zachowanie.

2. Łatwe dodawanie warunków za pomocą argumentów i niestandardowego porządku po wdrożeniu

3. Używaj wielu niestandardowych filtrów i pozbądź się wszystkich działań, które należy utworzyć, na przykład użytkownik może mieć identyfikator, nazwę itp. Jako argumenty i wykonać filtrowanie. Dodatkowo filtry można zastosować również na grupach użytkowników.

4. Łatwość testowania API poprzez tworzenie plików zawierających wszystkie zapytania GraphQL i mutacje.
5. Mutacje są proste i łatwe do zaimplementowania po zrozumieniu koncepcji.
6. Potężny sposób na pobieranie wielu poziomów danych.
7. Obsługa funkcji Voyager i GraphiQL UI lub Playground ułatwia przeglądanie i używanie.
8. Łatwość dokumentowania przy definiowaniu schematu z poprawnymi metodami opisu.

Myślę, że w tej chwili graphql musi być częścią architektury zaplecza, ponieważ w celu przesłania plików nadal korzystasz ze zwykłego interfejsu API