Published on: 28 May 2025
The landscape of API frameworks has changed, REST, tRPC, gRPC, GraphQL,... all have good things and bad things, lets talk about them.
Introduction
For a long time, choosing how to design your API was simple: REST was the default. It is simple, stateless, and supported by every tool you could think of.
But in 2025, the landscape is expanding with more stable frameworks, and it is much more nuanced:
- tRPC offers type-safe communication between frontend and backend — without needing to define schemas twice.
- GraphQL gives clients flexible querying and built-in documentation.
- gRPC brings fast communication and strongly typed contracts.
With these tools maturing … How do you choose the right API architecture for your project today? Lets talk about it.
Quick Overview
REST: The Old Reliable
| Pros | Cons |
|---|---|
| Universal support | Can result in over-fetching |
| Stateless | Lacks type safety |
| Easy to debug | multiple queries to get complex data |
REST is still everywhere, and it’s the best option when:
- You need public APIs or integrations with third parties.
- You want a language-agnostic interface.
- You prioritize human readability and maturity.s
GraphQL: Flexible by Design
| Pros | Cons |
|---|---|
| Single endpoint | Complexity |
| precise querying | Harder to cache |
| great tooling | Requires extra attention to security |
Use GraphQL when:
- Your frontend team wants control over what data they request.
- You need to aggregate multiple data sources.
- You’re building mobile-first apps where minimizing over-fetching is key.
PS: about my security concerns read this amazing post: The complete GraphQL Security Guide: Fixing the 13 most common GraphQL Vulnerabilities to make your API production ready
gRPC: High Performance, Strong Contracts
| Pros | Cons |
|---|---|
| Protobuf is fast | Not human-readable |
| Bi-directional streaming | Complicated debugging |
| Great for internal services | Limited browser support |
gRPC is great for:
- Microservice-to-microservice communication.
- Low-latency, high-throughput systems (e.g., video, ML pipelines).
- Environments where you control both sides of the communication.
tRPC: Type Safety Without Schemas
| Pros | Cons |
|---|---|
| End-to-end type safety | TypeScript-only |
| No need for schemas | Tightly couples frontend/backend |
| No Under/Over-Fetching | Relatively new, not as widely adopted yet |
tRPC is a go-to when:
- You’re building a TypeScript fullstack app (like Next.js).
- You want to move fast with full IDE support and minimal redundancy.
- Your frontend and backend live together (e.g., monorepo).
What Are You Optimizing For?
Now, this is as with all the projects, what are you looking to achieve?
| Goal | Best Fit |
|---|---|
| Frontend flexibility | GraphQL |
| DX + typesafety (TypeScript) | tRPC |
| Public/open API | REST |
| Microservice communication | gRPC |
| Easy caching & debugging | REST / tRPC |
| Rapid prototyping | tRPC / GraphQL |
| Strict performance | gRPC |
You can even combine them:
- Use tRPC internally, and REST externally.
- Power GraphQL queries with underlying REST or gRPC services.
- Expose a REST gateway over gRPC for public consumption.
The world is yours!
But we are in the real world
and there is no silver bullet. However, the best engineering teams make intentional choices based on their context:
- Do you own both sides of the API?
- Are you building for humans or machines?
- Will this be consumed across languages, or just within a TS stack?
- Where lies the expertise of your team?
What will I do for my next projects this 2025
If I’m building a fullstack SaaS in TypeScript -> I reach for tRPC. If I need flexibility and multiple frontend consumers -> I lean on GraphQL. If I’m designing internal high-performance services -> gRPC, no doubt. If I need to expose a stable API to third parties -> REST still does the job.
But, it will depend too in the resources I have available on that time…
Wrapping up
The API world is richer and more complex than ever. And that is awesome because it means we have better tools for different jobs.
The key in 2025 is as always: do not to follow hype, take your time to understand the tradeoffs of each option and apply them thoughtfully. The best API isn’t the one with the coolest tech, it’s the one that best fits your team, your stack, and your users.
