Backend / Mikroserwisy

gRPC

HTTP/2 + Protocol Buffers + type-safe code generation. gRPC to domyślny wybór dla komunikacji internal microservice-to-microservice gdy performance i type safety są priorytetem.

~10x mniejszy

Protobuf vs JSON

4 (Unary+3 stream)

Typy komunikacji

HTTP/2

Protokół

Google (2015)

Twórca

4 typy komunikacji gRPC

gRPC obsługuje nie tylko klasyczny request-response, ale też trzy warianty streamingu — natywnie przez HTTP/2.

Unary

1 request → 1 response

CRUD, query, command

Przykłady: GetUser, CreateOrder

Server Streaming

1 request → N responses (stream)

Feeds, progress, live data

Przykłady: SubscribePrices, StreamLogs

Client Streaming

N requests → 1 response

File upload, batch insert

Przykłady: UploadFile, BulkCreate

Bidirectional

N requests ↔ N responses

Chat, gaming, collaboration

Przykłady: LiveChat, SharedEditor

gRPC vs. REST — porównanie

gRPC i REST to komplementarne narzędzia. gRPC wygrywa dla internal microservice communication, REST dla public APIs i browser clients.

Aspekt	gRPC	REST
Protokół	HTTP/2 (multiplexing)	HTTP/1.1 lub HTTP/2
Serializacja	Protobuf (binarny, ~10x mniejszy)	JSON (tekstowy)
Contract	.proto (schema-first, wymagany)	OpenAPI (opcjonalny)
Code gen	Type-safe klienty i serwery	Opcjonalne (Swagger Codegen)
Streaming	Natywny (4 typy)	WebSocket lub SSE
Browser support	gRPC-Web (przez proxy)	Natywny
Czytelność	Binarny — nie czytelny	JSON — czytelny
Latency	Niższy (protobuf + HTTP/2)	Wyższy

Często zadawane pytania

Co to jest gRPC i czym różni się od REST?

gRPC (Google Remote Procedure Call) to nowoczesny framework RPC stworzony przez Google, oparty na HTTP/2 i Protocol Buffers (protobuf). Pozwala na wywoływanie metod zdalnych serwisów jak lokalnych funkcji, z automatycznym generowaniem klientów w wielu językach. Główne różnice gRPC vs REST: Protokół: gRPC używa HTTP/2 (multiplexing, header compression, server push). REST używa HTTP/1.1 lub HTTP/2. Serializacja: gRPC używa protobuf (binarny, 5-10x mniejszy niż JSON). REST używa JSON (tekstowy, czytelny). Contract: gRPC wymaga .proto file (schema-first). REST jest opcjonalnie opisany przez OpenAPI/Swagger. Komunikacja: gRPC wspiera 4 typy: Unary, Server Streaming, Client Streaming, Bidirectional Streaming. REST: request-response (Unary). Code generation: gRPC generuje type-safe klientów i serwery w każdym języku z .proto. REST: opcjonalne narzędzia generacji. Kiedy gRPC jest lepsze od REST: Komunikacja microservice-to-microservice (niski latency). Streaming danych (real-time feeds). Poligeniczne środowiska (wiele języków). Performance-critical paths. Kiedy REST jest lepsze: Public APIs (wszyscy rozumieją REST). Browser-to-server (gRPC-Web jest dostępny ale mniej popularne). Prostota i szeroka znajomość.

Protocol Buffers — jak działają i jak definiować schematy?

Protocol Buffers (protobuf) to mechanizm serializacji danych stworzony przez Google. Dane są serializowane do binarnego formatu — kompaktowego i szybkiego. Definicja schematu w .proto file: definiujesz messages (odpowiednik JSON object) i services (metody RPC). Kluczowe elementy: message — struktura danych. field — pole w message z typem i numerem (tag). service — kolekcja RPC metod. rpc — pojedyncza metoda z request i response type. Typy danych: skalarne (int32, int64, float, double, bool, string, bytes), złożone (inne messages), enum, repeated (list/array), map (key-value). Field tags: każde pole ma unikalny numer (1, 2, 3...). Służą do identyfikacji w binarnym formacie. Numery 1-15 są zakodowane na 1 bajt — używaj ich dla często używanych pól. Backward/Forward compatibility: możesz dodawać nowe pola (z nowymi tagami) bez breaking change. Stary klient ignoruje nieznane pola. Nigdy nie zmieniaj tagów ani typów istniejących pól. Generowanie kodu: protoc kompilator generuje klasy/structs dla Java, Python, Go, C++, C#, JavaScript/TypeScript, Kotlin, Swift, PHP i inne. W Go: protoc-gen-go. W Java: grpc-java. Binarny format: protobuf jest 5-10x mniejszy niż JSON i 2-5x szybszy w serializacji.

Cztery typy komunikacji gRPC — kiedy używać?

Cztery typy gRPC: Unary RPC: klient wysyła jeden request, serwer odpowiada jednym response. Identyczne z REST request-response. Use case: większość operacji CRUD. Przykład: GetUser(UserRequest) returns (UserResponse). Server Streaming RPC: klient wysyła jeden request, serwer wysyła strumień wielu response. Use case: real-time feed (stock prices, log streaming, progress updates). Przykład: SubscribeToUpdates(Request) returns (stream Update). Client Streaming RPC: klient wysyła strumień wielu requestów, serwer odpowiada jednym response. Use case: upload dużych plików w częściach, agregacja danych. Przykład: UploadFile(stream FileChunk) returns (UploadResult). Bidirectional Streaming RPC: obie strony wysyłają strumień wiadomości niezależnie. Use case: chat, collaborative editing, real-time gaming. Przykład: Chat(stream ChatMessage) returns (stream ChatMessage). Zalety HTTP/2 dla streamingu: HTTP/2 multiplexing pozwala wielu streamom współdzielić jedno połączenie TCP. Brak head-of-line blocking (problem HTTP/1.1). Long-lived connections — idealne dla streaming. Flow control — serwer może kontrolować tempo wysyłania przez klienta. Practical use: Bidirectional streaming używany przez Google w dużych systemach: Kubernetes API server, Google Cloud Pub/Sub, GCP Dataflow.

gRPC w mikrousługach — ecosystem i narzędzia?

gRPC ecosystem: grpc-gateway: automatycznie generuje REST-to-gRPC proxy z .proto definicji. Możesz udostępnić zarówno gRPC jak i REST API z jednego serwisu. Idealny dla public API + internal gRPC. gRPC-Web: pozwala przeglądarkom używać gRPC (nie bezpośrednio — przez proxy). Envoy jako proxy. Alternatywnie: grpc-web biblioteka + grpcwebproxy. gRPC Reflection: serwis udostępnia swój schemat runtime. Pozwala narzędziom (grpcurl, evans) na discovery i testing bez .proto pliku. Narzędzia do testowania gRPC: grpcurl — curl dla gRPC. evans — interaktywny gRPC klient (REPL). BloomRPC — GUI klient (jak Postman dla gRPC). Postman — od 2022 obsługuje gRPC. Load Balancing: gRPC ma problem z load balancing — trwałe HTTP/2 połączenia trafiają do jednego backend. Rozwiązanie: client-side load balancing (serwis sam wybiera instancje). gRPC-aware load balancer (Envoy w Service Mesh). Service Mesh integration: Istio i Linkerd mają native gRPC support — load balancing, retries, timeouts, tracing per method. gRPC status codes: 16 standardowych kodów błędów (OK, NOT_FOUND, INVALID_ARGUMENT, UNAVAILABLE, DEADLINE_EXCEEDED). Mapowanie na HTTP status codes przez grpc-gateway.

Migracja z REST do gRPC — kiedy i jak?

Migracja z REST do gRPC: Kiedy warto migrować: Masz wewnętrzną komunikację microservice-to-microservice przez REST. Latency komunikacji wewnętrznej jest problemem. Masz poligeniczny ekosystem (Java backend + Go sidecar + Python ML service). Budujesz streaming capabilities (real-time features). Strategia migracji: Nie musisz wybierać: grpc-gateway pozwala na jednoczesne REST i gRPC z jednego serwisu. Migruj stopniowo — zacznij od najczęstszego internal call path. Definiuj schema-first: .proto jako kontrakt między teamami. Lepszy niż OpenAPI dla internal services — type-safe generated clients. Backward compatibility: traktuj .proto file jak public API. Zmiana wymaga versioning (package v1, v2). Pułapki migracji: Debugging trudniejszy niż REST (binarny format). Używaj gRPC reflection i grpcurl. Load balancing — nie zapomnij o gRPC-aware LB lub Service Mesh. gRPC-Web jeśli browser clients. Error handling: gRPC status codes są inne niż HTTP status codes — dostosuj error handling. Adoption: gRPC jest popularny w: Google (wewnętrznie wszędzie), Netflix, Square, CoreOS, etcd, Kubernetes API. Język-specific performance: Go + gRPC = excellent performance. Java + gRPC = dobry. Python gRPC = gorszy (GIL), rozważ asyncio. Rust + tonic (gRPC framework) = najlepsza wydajność.

Czytaj dalej