Grpc

For engineers coming from Magento PHP, the shift to Go microservices isn’t just a language change — it’s a fundamentally different way of organizing code. Magento has controllers, models, blocks, helpers, and plugins. Go with Kratos v2 has exactly five layers, each with a precisely defined responsibility. Answer-first: A production Go microservice on this platform follows the Kratos v2 directory convention (api/ → cmd/ → internal/biz/ → internal/data/ → internal/server/), uses Google Wire for compile-time dependency injection, exposes both HTTP and gRPC simultaneously on different ports (8xxx/9xxx), and imports a shared common library at v1.9.5 that provides outbox, caching, worker, metrics, and logging — standardized across all 21 services. ...

Every public-facing API in the Composable Commerce Platform starts as a .proto file. The code — Go gRPC handlers, TypeScript SDK, HTTP routes, request validation, error codes — is generated from that contract. This article documents the conventions that make that system work. Answer-first: Internal services communicate via gRPC (type-safe, binary, ~7× faster than JSON over REST). External clients (browser, mobile app) use REST via the Gateway Service (port 8000). The proto file is the single source of truth for the API contract — and three proto conventions require special attention for engineers coming from Magento: the Money type (never use float for prices), cursor-based pagination (never use offset), and proto-level field validation (validation declared in the contract, not in business logic). ...

Prerequisite: This is Part 12 of the System Design Masterclass. Previous parts built the reliability patterns — this part covers comparing communication protocols and data formats for microservice communication. Answer-first: gRPC is optimized for internal microservices using binary Protobuf serialization over multiplexed HTTP/2 or HTTP/3 streams. REST uses standard JSON over HTTP/1.1 or HTTP/2, serving as the default for public APIs. GraphQL operates as an aggregator at the API gateway or Backend-for-Frontend (BFF) layer, allowing clients to query specific properties, but requires complexity limits and DataLoader batching to prevent server degradation. ...

Building a simple API that calls Graphhopper via http.Get is easy. Building a Principal-level API Gateway that survives 10,000 concurrent riders requesting routes without crashing is a masterclass in Distributed Systems. Answer-first: Graphhopper is a heavily CPU-bound downstream service. If your Golang API blindly accepts traffic and forwards it, a slight slowdown in Graphhopper will cause your Goroutines to pile up, exhausting your server’s RAM and triggering a cascading failure. You must implement a “Defense in Depth” strategy using Concurrency Bounding, Circuit Breakers, and Asynchronous Pub/Sub. ...

Why gRPC for Go Microservices? Answer-first: gRPC is the right choice for Go microservices when you need: binary-efficient serialization (Protobuf is 3–10× smaller than JSON), bidirectional streaming for real-time data, strongly-typed contracts across services, and sub-millisecond inter-service latency. Google, Uber, Netflix, and Square use gRPC as the primary inter-service communication protocol. This guide shows you how to build production-grade Go gRPC services from scratch. The key advantages over REST: gRPC REST/JSON Serialization Protobuf (binary, schema-enforced) JSON (text, schema-optional) Payload size 3–10× smaller Baseline Streaming Unary, Client, Server, Bidirectional HTTP/2 SSE (server-only), WebSocket (separate) Contract .proto file (language-agnostic codegen) OpenAPI (opt-in, often stale) Latency ~0.5ms p50 inter-service ~2–5ms p50 inter-service Browser support gRPC-Web (needs proxy) Native Best for Internal microservices, streaming Public APIs, browser clients Step 1: Define Your Service with Protobuf Create the contract first — Protobuf schema drives code generation for all languages. ...