Comparison
Gortexa is a contract-first gRPC framework whose distinguishing choice is that one h2c port serves gRPC, HTTP/JSON and MCP, with all three sharing one interceptor chain, one error-mapping table and one auth path. The comparisons below are about that choice: what it buys, and what it costs.
Gortexa vs plain grpc-go
Section titled “Gortexa vs plain grpc-go”grpc-go is the transport. Everything above it — the REST surface, the interceptor order, the error mapping, the health model, the MCP bridge — is yours to write and keep consistent.
| grpc-go | Gortexa | |
|---|---|---|
| gRPC server | yes | yes (grpc-go underneath) |
| HTTP/JSON | wire grpc-gateway yourself | built in, same port |
| MCP for AI agents | write it | built in, same port and chain |
| Interceptor order | your decision, per service | fixed eight stages, fail-loud if absent |
| Error → HTTP/gRPC/MCP | hand-mapped per transport | one registry, three transports |
| Health, config, OTel | assemble | included |
Choose grpc-go directly when you want no opinions, or when you need transport features Gortexa’s shared port cannot express — see the limits section.
Gortexa vs connect-go
Section titled “Gortexa vs connect-go”The closest comparison, and the one worth reading carefully. Connect and Gortexa both multiplex protocols on one port; they multiplex different protocols.
| connect-go | Gortexa | |
|---|---|---|
| Protocols on one port | Connect, gRPC, gRPC-Web | gRPC, HTTP/JSON (grpc-gateway), MCP |
| Browser clients | first-class (Connect + gRPC-Web) | via HTTP/JSON |
| AI-agent clients | not addressed | MCP tools generated from proto annotations |
| HTTP/1.1 | supported | the port is h2c; HTTP/1.1 for the JSON surface |
| Governance | you compose interceptors | fixed chain, shared by all three transports |
| Scope | an RPC library | a framework with config, health, MQ, cache, storage |
Pick connect-go if browser clients and a simple, unopinionated RPC library are the goal. Pick Gortexa if you want the REST surface generated from google.api.http annotations and want AI agents to call the same RPCs through the same auth and validation.
Gortexa vs grpc-gateway alone
Section titled “Gortexa vs grpc-gateway alone”Not a competition: Gortexa uses grpc-gateway for its HTTP/JSON surface. Running grpc-gateway yourself typically means a second listener and a second process boundary, plus your own answer for how a gRPC status becomes an HTTP status. Gortexa’s delta is that the gateway dials the gRPC server over an in-process loopback, so a JSON request traverses the same eight stages as a gRPC one and lands in the same error table.
Gortexa vs Buf
Section titled “Gortexa vs Buf”Also orthogonal. Buf is proto tooling — lint, breaking-change detection, codegen, the schema registry — and Gortexa runs it: gortexa regen is buf lint → buf breaking → buf generate. If you already use Buf, Gortexa fits on top of it rather than replacing it.
Gortexa vs Kratos, go-zero and go-kit
Section titled “Gortexa vs Kratos, go-zero and go-kit”These are general Go microservice frameworks with wider scope: service discovery, config centres, code scaffolding across many transports, sometimes their own DSL. Gortexa is narrower on purpose — one port, three protocols, protobuf as the only source of truth — and deeper on the AI surface, which none of them address today. If you need service discovery or a multi-datacenter control plane out of the box, those frameworks give you more; if you want a small, opinionated core where an LLM tool call is governed exactly like a human request, Gortexa is the tighter fit.
When not to use Gortexa
Section titled “When not to use Gortexa”Stated plainly, because the limits decide the choice more often than the features:
- You need grpc-go’s full transport semantics on the public port. External gRPC on the shared h2c port runs in grpc-go’s
ServeHTTPhandler mode, so transport-level options —KeepaliveParams,KeepaliveEnforcementPolicy,MaxStreams,InitialWindowSize— are inert there. Keepalive enforcement on a public gRPC surface means splitting gRPC onto its own listener. - You need gRPC-Web. Gortexa does not multiplex it; connect-go does.
- You cannot run Go 1.27. The framework targets it (Go 1.21+ suffices as a bootstrap, since
GOTOOLCHAINfetches the rest). - You want to choose your own interceptor order. The eight stages are fixed by design. You can add your own interceptors inside the chain and swap the auth stage’s implementation, but not reorder it.
- You do not want protobuf as the source of truth. Every surface here is generated from proto; a JSON-first or hand-written-handler service is fighting the design.
Is Gortexa a replacement for grpc-go?
Section titled “Is Gortexa a replacement for grpc-go?”No — it is built on grpc-go. Gortexa supplies the layers above the transport: the multiplexed port, the fixed interceptor chain, the shared error model and the MCP bridge.
Can I use Gortexa with an existing Buf setup?
Section titled “Can I use Gortexa with an existing Buf setup?”Yes. Gortexa invokes buf lint, buf breaking and buf generate as its codegen pipeline, so an existing buf.yaml and BSR workflow carry over.
What does Gortexa do that connect-go does not?
Section titled “What does Gortexa do that connect-go does not?”It exposes annotated RPCs as MCP tools on the same port, dispatched through the same interceptor chain, so an AI agent’s tools/call passes the same auth and validation as a human request. It also generates the REST surface from google.api.http annotations via grpc-gateway.
Does adding MCP mean AI agents bypass my authorization?
Section titled “Does adding MCP mean AI agents bypass my authorization?”No. MCP tools/call is dispatched over an in-process loopback into the same gRPC server, so it traverses recover, request-id, logging, load shedding, rate limiting, the circuit breaker, auth and validation exactly like any other call.