GraphQL: Następca REST. Seria filmów #bezZbędnegoGadania
Część z Was wie, że od dłuższego czasu tworzę konkretne filmy dla programistów - bez zbędnego gadania. Seria o REST API przypadła Wam do gustu. Teraz czas na GraphQL, tworzona przede wszystkim z myślą o tych, którzy jeszcze z niej nie korzystają. Have fun!
overment z- #
- #
- #
- #
- 140
Komentarze (140)
najlepsze
Plus tego rozwiązania jest przede wszystkim taki, że masz elastyczność pytania o dane.
Korzystają z tego gracze typu Facebook czy Netflix. Wygląda na to że jest solidne.
/ ... chociaż, ostatnio widziałem jakiś news w którym pisali
@niko444: a co w tym złego. To tak jakbyś mowił, że rest to taki sql, bo operujesz na zasobach (tabele) przy użyciu predefiniowanych operacji (SELECT vs GET, INSERT vs POST)
Ziemniak, nastepca gruszki.
GraphQL ma inne zastosowania niż REST. Rozwiązuje inne problemy, wprowadza inne złożoności, oba mają inne ograniczenia, nadają się do innych systemów w innej skali przemysłowej. GQL zdecydowanie nie jest żadnym następca RESTa, tak samo jak SOAP nie jest następcą REST.
https://spf13.com/post/soap-vs-rest/
https://blog.apollographql.com/graphql-vs-rest-5d425123e34b
Teraz pracuję defacto 2-3h dziennie max, 4 jak musze zrobić calla, najcześciej siedzę od 9-12, reszte dnia mam wolnego. Mogę też zabrać lapa do plecaka i jechać gdziekolwiek mi się podoba, co też robię. Mogę pojechać z dziewczyną na mazury albo spedzić czas ze starzejącymi się rodzicami. Wcześniej pracowałem w "dużej zagranicznej korporacji" gdzie
Komentarz usunięty przez moderatora
@Nicolai przeglądałem ostatnio Kotlina. Jestem pod wrażeniem, pomimo tego że do Javy naturalnie jest mi daleko.
GraphQL jest najbardziej znienawidzona technologia wsrod moich znajomych programistow.
Wydajnosciowo to jest zalosne.
Implementacja cache to droga przez meke.
To zostalo zaprojektowane pod Facebooka i tam sie zspewne swietnie sprawdza, ale jak masz swoja aplikacje hackowac na milion sposobow tylko po to by byc „trendy” to masz priorytety do wymiany. Poza FB praktycznie nie ma
Ale działa to też w drugą stronę - GraphQL istotnie bardzo ciężko cachować, w przeciwieństwie do RESTa gdzie zapytania są o wiele bardziej "ustandaryzowane". Osobiście nie
Samo porównanie GraphQL i REST w różnych scenariuszach to ciekawy temat na film.
@overment Subskrybuję od dawna głównie z tego powodu. Temat jest zawsze poruszony zwięźle i bez zbędnego gadania. W 5 minut jest przekazane więcej informacji niż w poradnikach które mają pół godziny
https://twitter.com/kellabyte/status/1059956838744158213
Tu też jest fajne porównanie:
https://goodapi.co/blog/rest-vs-graphql
Temat jest mocno kontrowersyjny, bo ludzie źle podchodzą do GraphQL. To rozwiązanie zostało stworzone w Facebooku, żeby rozwiązać konkretne problemy, które FB miał. To nie jest żadne silverbullet. ALE w niektórych rozwiązaniach (głównie wokół wystawiania jakiś open API na świat, na pewno nie do komunikacji wewnętrznie między usługami) może być pomocny.
Nie wiem czy dobrze rozumiem, ale tak na prawdę, czyż nie jest tak, że REST, JSON-RPC i GraphQL opiera się na komunikacji przez protokół HTTP i odpowiednio sformułowanych żądań typu GET, POST, PUT itd.?
W takim standardowym REST wygląda to tak, że
@Serghio: Z grubsza tak, graphql wystawia jeden endpoint, z tym że komunikacja nie musi się odbywać po http.
W żądaniu dostajesz zapytanie o konkrente zasoby, które musisz pobrać z bazy czy innych źródeł i zwrócić. Są różne implementacje graphql po stronie servera w różnych językach. Korzystając z takiego rozwiązania musisz podać mapowania zasobów które przychodzą w zapytaniu
Co do zmian i przepisywanka - w REST i tak musisz utrzymywać kilka wersji jeżeli chcesz wdrożyć większe zmiany, więc nie widzę