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


101

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

Odpowiedzi:


95

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

1
„Musisz wcześniej zdefiniować schemat => dodatkowa praca przed uzyskaniem wyników” Nie widzę, jak to nie jest konieczne bez GraphQL? Oczywiście w przypadku niektórych frameworków w niektórych językach nie jest to wymagane, ale na przykład w przypadku interfejsu API języka Java nadal będziesz musiał opisać „schemat” w swoich modelach.
AntoineB

3
@AntoineB masz rację, w NodeJS jednak możesz łatwo stworzyć REST API bez zastanawiania się nad ogólnym schematem; po prostu zwróć rzeczy.
w00t

1
@ w00t i gdy tylko będziesz potrzebować parametrów z REST, uciekniesz się do analizy adresu URL, aby sprawdzić, czy typ parametru jest poprawny, wyrzucając 400, jeśli nie jest. Gdyby tylko było coś, czego można by uniknąć konieczności robienia tego ręcznie w każdym programie obsługi trasy: D
Capaj

Dzięki Spring Boot możesz po prostu wyciągnąć kilka artefaktów graphql-spring-boot-starteri graphql-java-toolszacząć. Utwórz swój schemat w zasobie .graphqls i utwórz klasy Resolver i gotowe. Uruchomienie działającego przykładu testowego zajęło około 10 minut.
Babyburger

1
Nie zgadzam się ze wszystkimi wadami, w rzeczywistości oszczędza to dużo czasu, sprawdź ten post xalitech.com/graphql-how-to-convince-your-boss
Ali

58

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.


2
Aby uzyskać nieokreśloną głębię, korzystam z odpowiedzi JsonType. Nie jest mocno wpisany, więc musisz sprawdzić dane wejściowe, ale może być bardzo przydatny.
w00t

3
REST zawsze miał problem z zapytaniami N + 1. Jedyną różnicą jest to, że REST projektowo uniemożliwia backendowi nawet podjęcie próby rozwiązania problemu. Zamiast tego przesuwa problem na frontend.
Capaj

40

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


1. W jaki sposób wybrane pola są istotne dla przyłączenia się do operacji? 2. Nie, jeśli używasz programu ładującego dane. 3. Możesz przeanalizować i przypisać costdo żądania. Nie stanowi to również problemu, jeśli używasz predefiniowanych zapytań, w których klient wysyła tylko identyfikator.
zoran404

1
zgodził się z 2. Z 3 to trochę dodatkowej pracy i co ważniejsze ppl muszą być świadomi.
aWebDeveloper

1
2. To już nie jest prawdą, ponieważ możesz użyć wielu narzędzi do ochrony swojego serwera. Na przykład link: howtographql.com/advanced/4-security Limity czasu, ograniczenie złożoności i głębokości. To tak, jakbyś powiedział, że twój REST będzie możliwy do DDoS, jeśli nie użyjesz ogranicznika szybkości. Wszystko się zmieniło
Yevhenii Herasymchuk

zaktualizowany punkt 2
aWebDeveloper

14

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.


4

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.

3

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

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.