# Comparison

Source: https://gortexa.sheng.page/en/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

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

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

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

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

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

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 `ServeHTTP` handler 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 `GOTOOLCHAIN` fetches 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.

## FAQ

### 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?

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?

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?

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.