Konrad Kowalski (rootsher)Principal Platform & Reliability Architect100110110101111010110011100101110111101011101011

Sposoby komunikacji z backendem: od formularza HTML do GraphQL

data
kategoria
Backend
także w
Frontend · Networking
czytanie
1 min / 235 słów

Frontend i backend komunikują się przez kilka warstw abstrakcji, które łatwo ze sobą pomylić.

fetch() nie jest REST-em. REST nie jest HTTP. GraphQL nie zastępuje transportu. RPC nie oznacza konkretnego protokołu sieciowego.

Ta seria porządkuje te pojęcia od dołu do góry.

Zaczynamy od najstarszego i nadal fundamentalnego modelu webu: formularza HTML, w którym request HTTP jest częścią nawigacji dokumentu. Następnie przechodzimy do AJAX i XMLHttpRequest, które po raz pierwszy oddzieliły komunikację z backendem od przeładowania strony.

Potem pojawia się fetch(), współczesny browser API do wykonywania requestów, i dopiero wtedy przechodzimy poziom wyżej: do sposobów projektowania samego API.

text
HTML Form
   |
   v
XMLHttpRequest
   |
   v
Fetch API
   |
   v
HTTP
   |
   v
REST / RPC / GraphQL

Każda z tych warstw odpowiada na inne pytanie.

text
HTML Form / XHR / Fetch
-> jak browser inicjuje request?

HTTP
-> jak request i response są przesyłane?

REST / RPC / GraphQL
-> jak aplikacja modeluje operacje i dane?

Seria nie będzie katalogiem bibliotek ani tutorialem frameworkowym. Nie interesuje nas, czy request wykonuje React Query, Axios, Angular HttpClient czy własny wrapper.

Interesuje nas mechanizm pod spodem:

  • co faktycznie wysyła browser,
  • kto definiuje semantykę requestu,
  • gdzie kończy się odpowiedzialność HTTP,
  • czym różni się zasób od operacji,
  • kiedy elastyczność API pomaga, a kiedy zwiększa koszt systemu.

Kolejne artykuły wynikają z ograniczeń poprzednich.

Formularz jest prosty, ale request oznacza nawigację. AJAX rozdziela te dwa mechanizmy. fetch() porządkuje browser API, ale nadal nie mówi nic o tym, jak projektować endpointy. REST modeluje zasoby, RPC operacje, a GraphQL przenosi część kontroli nad kształtem odpowiedzi do klienta.

Na końcu powinniśmy mieć jeden spójny model:

text
browser API
!=
transport protocol
!=
API architecture

Dopiero po rozdzieleniu tych warstw sensownie można rozmawiać o tym, jak frontend komunikuje się z backendem.