I still remember the first time I questioned REST.
It was back in 2017. I was knee-deep in a project for a health tech startup. The backend was RESTful, clean, predictable, and exactly what I’d built a hundred times before. But then came a change request from the frontend team:
“Can we get the patient profile with their latest appointment, doctor notes, lab results, but only the latest two, and only the summary?”
My response?
"Uh… I’ll need to create another endpoint."
And just like that, I found myself in an API endpoint rabbit hole, one that felt very familiar. Because, for all its simplicity, REST can get repetitive when apps start getting complex.
That project was one of many in my career where I began to rethink the “REST by default” approach.
My Journey With REST: The Comfortable First Love
I’ve been writing REST APIs since around 2012. Back then, REST felt like the gold standard. Clients wanted clean, well-structured endpoints that made sense:
- /users
- /users/:id
- /users/:id/posts
The idea of modeling everything as resources felt intuitive. It mapped well to how we think about data.
I used REST in finance dashboards, CMS platforms, and social media apps. It was reliable, well-documented, and had great HTTP support. Tools like Postman, Swagger, and even built-in browser behavior made development smoother.
But as time passed, our frontends got more demanding. Mobile apps wanted lighter payloads. Dashboards wanted complex nested data with minimal loading. React and Vue devs started asking for “just what we need, no more, no less.”
That’s when things got… clunky.
Enter GraphQL: A New Way of Thinking
In 2019, a client came to Bluell, the team I currently work with, and the client asked for a custom analytics dashboard. It was going to support multiple roles, dynamic charts, and heavy filtering. Frontend devs were tired of hitting three different endpoints just to render a single screen.
We decided to give GraphQL a shot.
Now, this wasn’t a small change. I had to wrap my head around schemas, resolvers, and type definitions, all new territory. But once the setup was done? The frontend team started smiling. Seriously.
Instead of requesting a user, their projects, and tasks in three separate calls, they wrote a single query:
{
user(id: "123") {
name
projects {
title
tasks(limit: 5) {
title
status
}
}
}
}
Boom. One request. Exactly what they needed. No more, no less.
That project was a turning point.
Where REST Still Wins
Despite GraphQL’s strengths, I haven’t ditched REST. Not even close.
There are still projects, like a public-facing API we built for a fintech client, where REST is a perfect fit. The endpoints are predictable. It supports browser caching natively. And if you’re building something that’s primarily CRUD-based, REST is faster to set up and easier to reason about.
I often tell junior devs: Don’t reach for GraphQL just because it’s shiny.
REST is still a workhorse.
Where GraphQL Shines
But if your app:
- has complex nested relationships,
- serves multiple clients (web, mobile, etc.),
- or requires high flexibility in data fetching…
Then GraphQL is worth the learning curve.
We used it for a learning platform last year. The client had four different types of users, such as admins, instructors, students, and guardians, all seeing different slices of the data. REST would have required a jungle of endpoints. With GraphQL, we let each client fetch just the data they needed.
It was fast. It was clean. And the best part? We didn’t need to modify the backend every time the UI changed.
REST vs GraphQL: My Personal Scorecard
Real Talk: When to Use What
Use REST if:
- You’re building a traditional web app with simple resource needs.
- You need easy caching and straightforward URLs.
- Your team is more familiar with REST, and time is tight.
Use GraphQL if:
- You want to avoid over-fetching/under-fetching.
- You’re working with multiple frontends.
- Your data has lots of relationships (e.g., users → posts → comments → likes).
Sometimes… you use both.
I've worked on projects at Bluell where REST handled authentication and payments (thanks to HTTP caching and middleware), while GraphQL powered the dashboard’s dynamic UI.
You don’t always have to pick sides. Just pick what solves your actual problem.
Lessons I’ve Learned Over Time
- Don’t follow hype, follow use case.
- Simple is better. If REST does the job, don’t complicate it.
- Talk to your frontend team. GraphQL often makes their life easier, which means fewer backend changes down the line.
- Tooling matters. REST is quick to get running; GraphQL takes investment upfront but pays off later.
Final Thoughts
After more than a decade of building software, I’ve stopped chasing the “best” solution. There’s no silver bullet. Only trade-offs.
REST is like a dependable car, maybe not flashy, but it gets you there.
GraphQL is like a custom-built electric bike: flexible, efficient, but requires tuning.
Know what you’re building. Know your team’s strengths. And choose the tool that fits, not the one that trends.
If you’re unsure which one to go with, don’t be afraid to experiment on a small feature or module first. That’s exactly how we started doing GraphQL, just a small proof of concept, and then gradually expanded once we saw the benefits.
Top comments (0)