Can one project mix REST, GraphQL and gRPC?

Yes — and mature systems usually are hybrids: REST for public APIs (best ecosystem compatibility), GraphQL at the BFF layer (multi-client aggregation), gRPC between internal microservices (performance and strong contracts). The unit of choice is the "interface boundary", not the "whole project".

How do you solve GraphQL’s N+1 problem?

The standard fix is the DataLoader pattern: batch multiple single-item queries within the same event loop into one bulk query, with cache dedup. Also add query depth and complexity limits at the gateway so a malicious or runaway deeply-nested query can’t take down the database.

Can gRPC be used directly by a browser front-end?

Browsers can’t speak gRPC directly (limited control over HTTP/2 framing); you need gRPC-Web plus a proxy (e.g. Envoy) to translate. So gRPC’s home turf is service-to-service and mobile/IoT clients; pure browser front-ends usually convert to REST or GraphQL at the gateway.

Will a small team regret starting with plain REST?

Most likely not. REST + OpenAPI is the lowest-migration-cost starting point: the fullest ecosystem for docs, tests, gateways and monitoring, and the easiest to hire for. Introduce a GraphQL BFF when you actually hit multi-client aggregation pain, and gRPC when internal call performance becomes a bottleneck — evolving by pain point is safer than designing it all up front.

REST vs GraphQL vs gRPC: A Decision Framework for Backend API Protocols (2026)

The three mainstream API protocols each have a clear zone of fit: REST for external resource-style APIs, GraphQL for multi-client aggregation and fast-iterating front-ends, gRPC for high-performance internal service-to-service calls. This piece gives a framework organized by "who the caller is", with a typical combined architecture and three anti-patterns.

Bottom line first

The first question in choosing a protocol isn’t “which is more advanced” but “who is the caller”:

Caller	First choice	Why
External developers / third-party integration	REST + OpenAPI	Ecosystem compatibility, doc toolchain, lowest cognitive cost
Your own multi-client front-ends (Web/App/mini-program)	GraphQL (BFF layer)	Aggregate multiple resources in one request; front-end iterates without waiting on back-end
Between internal services	gRPC	Strong contract (protobuf), low latency, streaming support

Mature systems don’t pick one of three — they mix by interface boundary in layers. Below, the real trade-offs of each protocol and how they combine.

1. REST: the default’s standing is unshaken

REST’s core advantage isn’t technical but ecosystem: the OpenAPI spec underpins a full toolchain for docs (Swagger UI), mocking, contract testing, SDK generation and API gateway policy; any language, any team can pick it up immediately.

Zone of fit: resource-style CRUD, public APIs, webhooks, anything needing HTTP caching semantics.

Real weakness: multi-resource aggregation means either multiple round-trips or back-end aggregation endpoints (which multiply and slowly get out of hand) — exactly the problem GraphQL solves.

Engineering baseline (applies whether or not you pick REST): contract-first (OpenAPI docs before implementation), an explicit versioning strategy (URL versioning or header versioning — pick one and hold it), unified error structure.

2. GraphQL: a front-end aggregation layer, not a back-end replacement

GraphQL’s correct place is the BFF (Backend for Frontend) layer: the front-end declares the shape of data it needs per page and gets it all in one request, so the back-end doesn’t write an aggregation endpoint per page. The payoff is largest when client shapes diverge (Web wants everything, App wants trimmed, mini-program wants minimal).

Be clear about the costs:

N+1 queries happen by default (resolvers fetch item by item); DataLoader batching is mandatory, not optional;
Caching gets complex: HTTP caching largely stops working (everything is POST /graphql), so you rely on client normalized caches (Apollo/urql) or persisted queries;
Runaway query risk: you must limit query depth/complexity at the gateway, or one deeply-nested query becomes a small DoS.

If your front-end is a single Web client with stable page shapes, GraphQL’s payoff won’t justify this complexity — plain REST is fine.

3. gRPC: the king of performance and contract for internal calls

Protobuf binary serialization + HTTP/2 multiplexing give latency and throughput clearly better than JSON over HTTP/1.1; the .proto file is a strongly-typed contract with cross-language code generation out of the box; it natively supports four streaming modes (unary, server-streaming, client-streaming, bidirectional), with almost no rival for real-time data pipelines.

The boundaries are just as clear: browsers can’t connect directly (needs gRPC-Web + proxy), binary messages aren’t human-readable (debug with grpcurl/reflection), and using it for public APIs will drive off half your integrators.

It’s the internal highway, not the public-facing front door.

4. A typical combined architecture

External developers ──REST(OpenAPI)──┐
                                     ├─ API gateway ──┐
Web/App/mini-program ─GraphQL(BFF)───┘                ├─ Service A ─┐
                                                       ├─ Service B ─┼─ gRPC inter-calls
                                                       └─ Service C ─┘

The gateway does auth, rate limiting and protocol translation; the BFF does aggregation and trimming; services talk gRPC. Each layer has a single responsibility, and replacing any layer doesn’t disturb the others.

Three anti-patterns

Using GraphQL for service-to-service calls — services don’t need “flexible data shapes” (the contract should be stable), yet you’ve imported N+1 and caching complexity; this is gRPC’s home turf.
Using gRPC for public APIs to show off — your integrators’ pain becomes your pre-sales cost.
“GraphQL-ifying” a REST endpoint — pseudo-flexible queries like GET /users?fields=a,b,c&include=orders.items collect the downsides of both: no GraphQL type system, and REST caching semantics lost. If you want flexibility, adopt GraphQL properly; if you want simplicity, hold the resource boundary.

AI Token Trading Platform Architecture — a real case of API gateway + internal service layering
Astro vs Next.js for Static Sites — the same decision-framework method applied to the front-end stack