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
- Odpowiedz
Komentarze (140)
najlepsze
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 na przykład wykonujemy żądanie typu GET na "endpoint"
/api/movie/1
, w odpowiedzi otrzymujemy JSON@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
Co do zmian i przepisywanka - w REST i tak musisz utrzymywać kilka wersji jeżeli chcesz wdrożyć większe zmiany, więc nie
Komentarz usunięty przez moderatora
GraphQl wygląda podobnie do SQL, gdyż jest następca FQL, w którym właśnie leciał SQL przez API. FQL plus rest = GraphQl