Odpowiedź.

Wybór architektonicznego stylu API zależy od wymagań dotyczących skalowalności, szybkości, elastyczności, zgodności i specyfiki konsumentów API.

• REST: Odpowiedni dla większości integracji wewnętrznych i zewnętrznych dzięki prostocie (HTTP, JSON), operacjom idempotentnym, cache'owaniu i szerokiemu wsparciu w narzędziach.
• gRPC: Używany do wysokiej wydajności i dwukierunkowego przesyłania strumieniowego, niskiej latencji, ścisłej schemy (Protobuf). Dobrze nadaje się dla usług wewnętrznych i mikroserwisów, gdzie wymagania dotyczące wydajności są wyższe niż dotyczące zgodności.
• GraphQL: Pozwala klientowi na samodzielny wybór struktury danych. Dobrze nadaje się dla zewnętrznych klientów mobilnych i front-endowych, gdy wymagana jest elastyczność i minimalizacja ruchu.

Przykład kodu (usługa gRPC w Go):

// Opis protokołu
service Greeter {
  rpc SayHello (HelloRequest) returns (HelloReply) {}
}

// Implementacja
func (s *server) SayHello(ctx context.Context, req *pb.HelloRequest) (*pb.HelloReply, error) {
  return &pb.HelloReply{Message: "Witaj " + req.Name}, nil
}

Kluczowe cechy:

• Różne style architektoniczne (REST, gRPC, GraphQL) rozwiązują różne problemy.
• gRPC lepszy dla wewnętrznych API z wysokimi wymaganiami dotyczącymi prędkości i typizacji.
• GraphQL optymalnie dla skomplikowanych publicznych API z wieloma wariacjami zapytań i dużą liczbą konsumentów front-endowych.

Pytania z zasadzki.

Czy można używać GraphQL jako zastępstwa dla wszystkich API REST lub gRPC?

Nie, GraphQL nie zawsze jest racjonalny — komplikuje cache'owanie, logowanie, utrudnia zabezpieczenie API i może być nadmiarowy dla prostych zadań, gdzie REST lub gRPC są prostsze i bardziej niezawodne.

Czy REST może zagwarantować ścisłą typizację?

Tylko częściowo. REST definiowany jest przez spójność kontraktów (Swagger/OpenAPI), ale z natury działa z luźnymi formatami (JSON/HTTP), a na przykład gRPC zapewnia żelazną statyczną typizację dzięki schemie Protobuf.

W jakich przypadkach nie zaleca się używania gRPC do publicznych API?

gRPC jest mniej kompatybilny z przeglądarkami i słabo integruje się z infrastrukturą HTTP/1.1 (np. proxy, zapory ogniowe). Dla publicznych API internetowych lepsze są REST lub GraphQL.