Zespoły inżynierskie wciąż marnują całe popołudnia na kłótniach o to, czy REST umarł, czy może gRPC uczyniło wszystko inne przestarzałym. Ta debata mija się z celem. Nie wybierasz najlepszego protokołu. Wybierasz odpowiednią granicę. Protokół, który świetnie sprawdza się wewnątrz klastra Kubernetes, zacznie się dusić, gdy przekażesz go tysiącom zewnętrznych programistów. Protokół, który oszczędza cenny transfer w aplikacji mobilnej, może zbankrutować Twoją infrastrukturę, jeśli otworzysz go na dowolne publiczne zapytania. Traktowanie tej decyzji jak konkursu popularności technologii cementuje dług technologiczny, który przetrwa każdego obecnego członka Twojego zespołu.
Zasada Granicy
Architektura polega na kompromisach, a nie na szukaniu zwycięzców. Właściwe pytanie to nigdy nie „Który jest najszybszy?” ani „Który jest najnowszy?”. Pytanie brzmi: „Kto znajduje się po drugiej stronie połączenia i co kontroluje?”. Protokoły to obiekty graniczne. Wybór niewłaściwego nie tylko Cię spowolni. On utrwala błędy w Twoim systemie na lata.
Publiczne API: REST nie jest nudny, jest odpowiedzialny
Gdy Twoim konsumentem jest zewnętrzny programista, którego nigdy nie spotkałeś, Twoje API jest produktem, a nie tylko interfejsem. Ten programista debuguje kod o drugiej nad ranem, mając do dyspozycji jedynie curl i kolekcję Postman. Jeśli musi zainstalować niestandardową bibliotekę klienta lub nauczyć się języka schematów przed pierwszym udanym wywołaniem, już go straciłeś.
REST przetrwał tutaj, ponieważ jest samym internetem. Metody HTTP, kody statusu i JSON to wspólny język. Buforowanie (caching) nie jest czymś dodanym na końcu; to infrastruktura, która już istnieje. Przeglądarki, sieci CDN i pamięci podręczne typu edge natywnie rozumieją nagłówki Cache-Control i walidację ETag. Możesz umieścić REST API za standardowym CDN i uzyskać natychmiastowe oszczędności w przepustowości bez pisania ani jednej linii logiki buforowania. Ma to znaczenie, gdy ruch publiczny jest nieprzewidywalny, a Ty płacisz za każdy gigabajt opuszczający Twoją chmurę.
GraphQL, w przeciwieństwie do niego, nakłada wysoki podatek na publiczną granicę. Publiczne punkty końcowe (endpoints) GraphQL wymagają analizy kosztów zapytań, ograniczania głębokości (depth limiting) i oceniania złożoności, aby zapobiec sytuacji, w której jedno nieostrożne lub złośliwe zapytanie zmiażdży Twoją bazę danych. Nie wysyłasz po prostu API; budujesz silnik wykonywania zapytań, strategię ograniczania liczby żądań (rate-limiting) i model rozliczania mocy obliczeniowej. Chyba że dysponujesz zapleczem operacyjnym największych platform, ten narzut jest nieodpowiedzialny w przypadku publicznej powierzchni styku. REST ustawia barierki ochronne domyślnie. Każdy endpoint robi jedną rzecz. Konsumenci pobierają dokładnie to, co oferujesz, a nie to, co tylko zdołają wymyślić.
Usługi wewnętrzne: Panuj nad całym łączem
Wewnątrz organizacji rozmowa się zmienia. Kontrolujesz zarówno klienta, jak i serwer. Możesz narzucić stos technologiczny dla każdej usługi w łańcuchu wywołań. To tutaj gRPC zarabia na swoje utrzymanie.
Po pierwsze, przestań traktować JSON jako świętość. Protocol Buffers serializuje dane około trzy razy szybciej niż JSON. Ładunki danych (payloads) są mniejsze, ponieważ format jest binarny. W obciążonej sieci wewnętrznej te milisekundy i megabajty kumulują się w realne pieniądze i niższe opóźnienia (tail latency). Co ważniejsze, Protobuf zapewnia ścisły kontrakt. Gdy zmieniasz typ pola lub zmieniasz nazwę wiadomości, błąd pojawia się w czasie kompilacji, a nie o trzeciej nad ranem na produkcji, gdy usługa zależna zaczyna wyrzucać wyjątki parsowania.
gRPC działa w oparciu o HTTP/2, więc otrzymujesz kompresję nagłówków, wielokrotne strumieniowanie (multiplexed streams) i rzeczywistą semantykę strumieniowania. Jeśli przesyłasz zdarzenia o wysokiej przepustowości między usługami lub wysyłasz aktualizacje w czasie rzeczywistym, strumieniowanie po stronie serwera oraz strumieniowanie dwukierunkowe są funkcjami natywnymi, a nie rozwiązaniami typu long-polling, naklejonymi na szare taśmy na framework typu request-response.
Jest jednak pewien haczyk: nie kieruj gRPC bezpośrednio do przeglądarki. Modele sieciowe przeglądarek nie obsługują HTTP/2 w taki sposób, jak tego oczekuje gRPC. Skończysz, próbując „wszczepić” grpc-web i proxy typu Envoy do swojego stosu tylko po to, aby przeglądarka mogła porozmawiać z backendem. To nie jest błąd; to sygnał graniczny. Trzymaj gRPC za firewallem, pomiędzy usługami, które sobie ufają, i traktuj złożoność jego debugowania jako cenę za szybkość. Dane binarne nie są tak czytelne w plikach logów jak JSON.
Złożone interfejsy UI i urządzenia mobilne: Nisza GraphQL
Nowoczesne ekrany mobilne to mozaika. Jeden widok może potrzebować profilu użytkownika,