Choosing how your front end talks to your back end shapes the next two years of development. REST, GraphQL and tRPC all work. They differ in how much they ask of your team and where they save time. This article compares them on the points that matter in real projects.
REST: simple, cacheable, universal
REST exposes resources at URLs and uses HTTP methods for actions. GET /orders/42 returns an order, and POST /orders creates one. Every language, tool and proxy understands it.
- Strengths: HTTP caching works out of the box, it is easy to debug with a browser or curl, and third parties can integrate without special libraries.
- Weaknesses: clients often fetch too much or make several calls to build one screen. Documentation and types drift unless you generate them from an OpenAPI file.
- Best for: public APIs, simple CRUD products, and teams with mixed skills.
GraphQL: ask for exactly what you need
GraphQL gives clients one endpoint and a typed schema. The client writes a query that lists the fields it wants and gets that shape back.
- Strengths: no over-fetching, one request for a whole screen, a self-documenting schema and strong tooling for mobile and multi-client products.
- Weaknesses: caching is harder because most requests are POST to one URL, query cost needs limits to stop abusive queries, and resolvers can cause N+1 database calls without batching.
- Best for: products with many clients, large teams that need a shared contract, and screens that combine data from several services. See our notes on GraphQL in enterprise projects.
tRPC: types without a schema layer
tRPC lets a TypeScript client call server functions with full type safety and no code generation. Change a server return type and the client shows an error immediately.
- Strengths: very fast development, no separate schema to maintain and excellent editor support.
- Weaknesses: it assumes TypeScript on both sides, it is not meant for public APIs and it ties the client and server together.
- Best for: a full-stack TypeScript app, such as a Next.js product with one web client.
Side-by-side comparison
- Learning curve: REST is lowest, tRPC is low for TypeScript teams, GraphQL is highest.
- Caching: REST is best, GraphQL needs client caches or persisted queries, tRPC relies on your data-fetching library.
- Type safety: tRPC is end to end, GraphQL needs code generation, REST needs OpenAPI generation.
- Third-party access: REST is the standard, GraphQL is possible, tRPC is not intended for it.
Questions that decide it
- Will outside developers use this API? Choose REST.
- Do you have several different clients with different data needs? Consider GraphQL.
- Is it one TypeScript web app owned by one team? Choose tRPC.
- Does your team already know one of them well? That knowledge is worth a lot, so favor it.
You can mix them
Many products use REST for public endpoints and webhooks, and a typed layer such as tRPC or GraphQL for their own front end. Pick per boundary instead of forcing one style everywhere. Whatever you choose, validate all input on the server, version carefully and document errors.
Common mistakes
- Adopting GraphQL for a small app where three REST endpoints would do.
- Skipping pagination and filtering on list endpoints.
- Returning different error formats from different endpoints.
- Leaving the API undocumented because "the types are enough".
A worked example: one dashboard, three styles
Imagine an invoicing dashboard that shows a customer, their last five invoices and the stock level of each item. With REST you might call /customers/7, /customers/7/invoices?limit=5 and then /products for the stock levels: three requests and some joining on the client. With GraphQL one query returns the exact shape the screen needs. With tRPC you call one typed server function and the editor warns you if the shape changes. None is wrong. The best choice depends on how many screens like this you have and who maintains them.
Practical rules that apply to all three
- Return consistent error objects with a code and a readable message.
- Use pagination from day one, because lists only grow.
- Add authentication and authorization checks on the server for every route or resolver.
- Log request IDs so a bug report can be traced.
- Write a short document of the main calls, even for a private API.
Where this shows up in our products
Business software has many screens that combine invoices, parties, products and payments, and each role sees different data. In our Lena Dena platform, the API enforces role-based access on the server, so a sales user cannot read what an accountant can, however the client asks for it. The same care applies when messages arrive from WhatsApp: a webhook is a plain REST endpoint that must verify the sender and respond quickly. Our WhatsApp automation follows that pattern, acknowledging the message first and processing it in the background.
We design and build APIs for web and mobile products. Browse our services and recent projects, or contact us to plan your architecture.