You’ve finally got that million-dollar app idea. You’ve picked your database, you’ve picked your frontend framework, and now you need to build an API to serve the data. Every tech blog, podcast, and YouTube video you consume expounds the modernity and virtues of GraphQL. It’s flexible. It’s scalable. It’s what the professionals use. It’s shiny. So you reach for it like a magpie towards a piece of glass on the sidewalk. But pull away, my friend.
Yes, you’ll be able to talk about your modern tech stack, ability to scale, and flexibility for clients with those future investors, but there are some problems. Your frontend is the only client. Your app doesn’t actually need much flexibility. And no investor is going to talk to you until you have users. What you need to do right now is get the product launched and keep it running smoothly so you can build your user base.
The rule for you is simple. Always choose simplicity over complexity unless forced to do otherwise. Complexity should solve a proven problem, not anticipate a hypothetical one. With that in mind, REST should be the default choice.
REST: The Simple, Proven Path of the Web
Your goal is to launch quickly, debug easily, and keep your maintenance budget low. So choose REST. It’s not “old” or “boring”; it’s a standard for a reason. REST’s primary value is that it forces you into a rigid structure that aligns perfectly with how the internet already works.
The Mechanics of Simplicity
REST is not a new query language or a proprietary spec. It is built directly on HTTP, the language of the web. And it is simple.
REST provides resources as URLs. Your endpoints are clean, discoverable URLs that map directly to resources.
Want users? Go to `/api/users`.
Want a specific user? Go to `/api/users/123`.
Actions in REST are instantly understandable using standard HTTP verbs: GET to read, POST to create, PUT/PATCH to update, and DELETE to, you guessed it, delete. Any developer who joins your team already understands this model. There’s no complex schema to learn, no new layer of tooling to install — just a browser, an IDE, and the standard rules of the road.
But there’s more to HTTP than just standardization. GraphQL has to be built to cache; REST gets it for free. You get built-in, industry-standard caching via headers like ETag and Cache-Control. Proxies, CDNs, and even the user’s browser know exactly how to cache your data without you writing a single line of application logic for it.
So what does all this simplicity get you? Are your users reporting problems getting data about their profiles? You KNOW the problem is happening in the `/api/users/123` endpoint under the GET action. You KNOW where to go in your code base to isolate the issue and fix it.
REST is More Than Enough Most of the Time
I hate to tell you, but your app is almost certainly a CRUD system. It doesn’t matter if it’s an admin dashboard, an e-commerce backend, or a new blog. All you’re really doing is Creating, Reading, Updating, and Deleting. And for that, REST is more than enough.
You don’t need to introduce a new query language and a complex resolver layer to tell the server: “Give me user 123’s name” or “create a new blog post.” Those operations fit perfectly into the existing, mature framework of HTTP.
Simplicity means faster development, lower maintenance costs, and a much lower headache factor when things go wrong at 3 AM. Don’t add unnecessary overhead when the simple, proven solution is already optimized for exactly what you need to do: ship.
GraphQL: Complexity and the Flexibility Nightmare
When you look past the buzzwords, GraphQL is a performance solution for a very specific problem. It was created at a massive scale (Facebook) to solve the problem of over-fetching — sending the client more data than it needed — especially in environments where clients (like a mobile app and a desktop site) had wildly different data requirements.
If your only client is your web app and your database is sitting on a fast server, you don’t have this problem yet. But if you do decide to jump into GraphQL, you need to understand the costs.
The Cost of Giving Clients an Inch
GraphQL’s core benefit — the ability for the client to ask for exactly what it wants — is its biggest hidden liability. In API design, if you give a client an inch of freedom, they will eventually set your server on fire.
With REST, you define discrete endpoints (e.g., `/api/users/123`). As the API developer, you can write and optimize a single, performant database query for that fixed path. GraphQL, however, lets the client write complex, deeply nested queries that can look like this: “Give me User A, all of their Friends, and all of those Friends’ most recent Posts.” This single query can explode into hundreds of unexpected database calls. As a result, you lose control over your server’s performance. Every new query a client writes becomes a potential performance attack vector that can shatter your database health and slow down every other user.
To prevent that attack vector, now you have to build and maintain complex layers of cost analysis and throttling to ensure no single client request is too demanding. This is a massive complexity overhead you never needed with the rigid structure of REST.
The Maintenance Pain Point
The simplicity of REST meant you knew exactly what data was being requested, how to secure it, and how to log it. With GraphQL, your logging and monitoring complexity skyrockets.
You no longer see clear, discrete requests like `GET /api/posts`. You just see `POST /graphql` with a massive JSON payload defining the query. Is a client complaining that their queries are too slow? Have fun finding out what query they’re even trying to execute. Once you find the query, it’s no longer a simple matter of tracking it through its fetching and transformation layers; you have to track it through multiple resolvers for every field. To avoid these headaches, monitoring tools now require deep parsing of that query payload to understand what the client was actually trying to do. This is a huge maintenance headache.
In REST, authorization often happens once at the endpoint level (e.g., “Can this user access the `/api/admin/users` endpoint?”). In GraphQL, because clients can combine data arbitrarily, you must secure every single field in every single resolver. If User A is allowed to see a Post’s title but not its sensitive internal status, you have to write and maintain that granular check deep inside the server logic for every field in the schema. This complexity makes your security model far more brittle and verbose.
Let’s again suppose your users are complaining about viewing their profiles, but this time you’ve served them via GraphQL. To even begin to debug the issue, you have to isolate the query they used (you did spend the time to set up a robust traceability system, didn’t you?), parse it through the schema and resolver layer, and only then can you hope to know where in the code base you have to start working. And because of GraphQL’s flexibility, there is a real chance that your fix for this issue could actually break other clients because they may be using those same resolvers in a different way.
The Self-Inflicted Paradox: Persisted Queries
The irony of GraphQL is that many major companies (like Apollo) now encourage a pattern called persisted queries.
To mitigate the security and performance risks of dynamic, client-defined queries, an API team registers a set of pre-approved, optimized queries on the server. The client no longer sends the full GraphQL query text; it only sends a small, unique ID. The server looks up the ID and executes the corresponding pre-optimized query.
This security measure effectively turns your complex GraphQL infrastructure back into a set of custom, fixed endpoints — exactly what REST offers — but with all the heavy, complex overhead of the GraphQL server, schema, and resolver layer still intact. You accepted maximum complexity for minimum flexibility gain. You’ve brought the performance cost down by completely removing the primary benefit of GraphQL.
Conclusion: Simplicity Wins the War
Adopting GraphQL when you have few to no users is the definition of preemptive optimization. It introduces massive cognitive load and infrastructure friction to solve performance problems that you likely won’t have until you scale to hundreds of millions of users using countless different clients across the globe. You don’t need a Formula 1 car and its pit crew to drive to the grocery store every week, and you don’t need GraphQL for your 100-user crud app.
REST’s maturity, standardization, and simplicity are its greatest features, not its liabilities. It allows your small team to move faster, debug more easily, and spend less time governing complexity.
So start with REST. Focus on shipping value and maximizing team efficiency. Only migrate or adopt GraphQL when a business-critical, measurable performance bottleneck (not just the idea of over-fetching) has been definitively proven. And, if you must use GraphQL, check out my colleague’s article on the core concepts to get started.
Remember that the extreme client flexibility of GraphQL comes with a massive cost in server governance, security, and performance tuning. Don’t choose complexity just because you can. Be pragmatic. The best architecture is the one that allows your team to ship the most value with the least friction.