Wpis z mikrobloga

GraphQL to język zapytań dla API, który został opracowany przez Facebook i społeczność
Obecnie jest to już dojrzała technologia, która zyskała uznanie na rynku.
Pokaże Ci co wyróżnia tą technologię, oraz czy może ona zastąpić nam klasycznego REST'a?
Oczywiście jest też wersja wideo
Nowy następca REST? Poznaj GraphQL!


#programowanie #programista15k #naukaprogramowania #java #backend #admin #technologia #informatyk #ciekawostki #graphql #bezpieczenstwo #jvm #byczazagroda
Pobierz SoftBull - GraphQL to język zapytań dla API, który został opracowany przez Facebook i...
źródło: comment_15826138539iBfhwkDDSjDKpDPWQv45x.jpg
  • 9
@SoftBull GraphQL noob z tej strony :) (nie mam komercyjnych wdrożeń, ale się bawiłem) i tak mnie zastanawia kilka rzeczy, piszesz:

Dla kontrastu w przypadku wykorzystania GraphQL wystarczy wykonanie tylko jednego żądania. Dlatego ten przykład dobrze obrazuje moc jaką dostarcza GraphQL. Unikamy wykonywania serii zapytań, na rzecz prostego, precyzyjnego sposobu absorbowania danych. W związku z tym przekłada się to na wydajność aplikacji a także znacznie mniejszy ruch sieciowy.


To nie jest przypadkiem
@opalczynski: dobrze, że pytasz :)
Tak, oczywiście - praca jest realizowana przez inne aspekty i pod względem wydajności nie potrafię się wypowiedzieć, bo nie zrobiłem testów/badań z tego zakresu (chociaż może warto?).
W każdym opowiadając Ci na pkt 1 i 2, to kiedy korzystamy z tradycyjnego REST i np. chcemy wyciągnąć godzinę otwarcia restauracji z maps api:
1. Wysyłamy żądanie (zapytanie) o pobranie ID restauracji na podstawie nazwy restauracji
2. Pobieramy
@SoftBull a którą cechę graphQLa byś uważał za generującą największą wartość? Bo ten argument o zmniejszeniu ruchu sieciowego do mnie nie mówi (tj. nie kwestionuję tego, faktycznie przy mądrym korzysztaniu z graphQLa można żądać tylko tego, czego potrzeba - w przeciwieństwie do RESTa, który jest 'fixed' - plus mniejsza liczba zapytań i uzyskamy efekt o którym mówisz) .
Jak dla mnie największa zaletą graphql jest zmniejszenie payloadu. Zamiast być skazanym na to co wypluje nam RESTowe API już na poziomie requestu określamy jakie dane chcemy dostać. W pewnych sytuacjach jest to bardzo duża wartość :)