The GraphQL Temptation
GraphQL promises everything:
- One endpoint
- Exactly the data you need
- Type safety
We tried it. It was over-engineered.
Why We Abandoned GraphQL
1. Complexity Explodes
Schema definitions. Resolvers. N+1 problems.
For a simple CRUD app, it's overkill.
2. Caching Is Hard
REST URLs cache easily. GraphQL queries don't.
Caching matters for performance.
3. Debugging Is Worse
REST: curl the endpoint. See response.
GraphQL: Tools, introspection, playground.
4. Over-fetching Rarely Matters
"We only fetch what we need."
How often do you fetch 20 fields when you need 5?
Rarely. The benefit is theoretical.
When REST Wins
1. Simple CRUD
If your API is mostly create/read/update/delete, REST is fine.
2. External Integrations
Third parties understand REST. They don't know GraphQL.
3. Caching Requirements
REST caching is simple. CDN-friendly. Fast.
4. Team Familiarity
If your team knows REST, use REST.
When GraphQL Makes Sense
1. Complex Frontend Requirements
If your React app needs flexible data fetching, GraphQL shines.
2. Mobile Apps
Bandwidth matters. Fetch only what you need.
3. Public APIs
If developers build on your API, GraphQL's flexibility helps.
The Decision Framework
| Situation | Choice |
|---|---|
| Simple CRUD | REST |
| Complex queries | GraphQL |
| Mobile app | GraphQL |
| External API | REST |
| MVP | REST |
The Honest Answer
For MVP: REST.
Ship faster. Debug easier. Team learns faster.
GraphQL is powerful. It's also complex.
Complexity is the enemy of MVPs.
