Here’s how I approached choosing between REST and GraphQL in recent projects:
The context:
I’ve worked with both REST and GraphQL, especially with Hasura for auto-generating GraphQL APIs. The decision often comes up when architecting new APIs for SaaS products or internal platforms. Choosing the right one affects team velocity, frontend/backend boundaries, and observability.
Options considered:
🔹 Traditional REST API (NestJS + OpenAPI)
🔹 GraphQL (custom backend or Hasura)
🔹 tRPC for fullstack TypeScript
🔹 Hybrid approach
What I chose & why:
I leaned towards REST or tRPC for new projects, unless there’s a clear need for GraphQL’s flexibility (e.g., highly dynamic UI with complex joins).
Why REST/tRPC?
✅ Easy to get started (both frontend & backend)
✅ Mature tooling: OpenAPI, Swagger, Postman, etc.
✅ Great support in observability stacks (Datadog, Grafana Labs, Elastic ELK, Amazon Web Services (AWS) CloudWatch)
✅ Predictable, straightforward error handling
Why GraphQL is tempting (especially with Hasura):
✅ Powerful and flexible querying—perfect for frontend teams
✅ Fewer round trips thanks to query joins
✅ Strong developer experience for frontend-heavy apps
But the downsides:
❌ Steeper learning curve for backend
❌ Performance debugging is harder
❌ Not as well supported in common observability tools
❌ Overfetching/underfetching still possible if not managed carefully
❌ Security concerns require extra attention (e.g. query depth limiting)
What I learned from it:
GraphQL shines when the frontend is complex and teams are experienced with the tooling. But for most use cases, REST (or tRPC) offers a better developer experience, observability, and maintainability, especially in cross-functional teams with limited GraphQL experience.
On my next project, I’ll start with REST or tRPC unless there’s a compelling reason to go GraphQL. The “cooler tech” isn’t always the better one, and trade-offs always matter.
Curious how you’d tackle this decision?
Drop your thoughts in the comments, or DM me to chat more. 👇
