GraphQL vs REST: My Verdict After 3 Projects

Project one: falling for GraphQL

In 2024, I introduced GraphQL for the first time while building an internal admin dashboard. Being able to request exactly the data you need from the frontend was compelling. With REST, I would've had to make 3 separate API calls for user info, order history, and shipping status. GraphQL did it in one query.

Apollo Client's cache was great too. Re-requesting the same data came straight from cache with no network call. Initial setup took 3 days, but development was pretty fast after that.

That was the good part

The problem was schema management. When the backend developer changed the schema, the frontend had to update queries to match, and sometimes they got out of sync. It's supposed to be type-safe, but when errors blow up at runtime, is it really type-safe?

And the N+1 problem. Since the frontend can freely request related data, someone wrote a deeply nested query that generated 147 database queries. Fixed it with DataLoader, but debugging ate up an entire day.

(147 queries. When you give the frontend too much freedom, this is what happens.)

Project two: back to REST

The next project had a team of 6 with a clear frontend-backend split. I wanted to use GraphQL again, but the backend team pushed back. "We know REST -- why switch?"

So we went with REST. It felt a bit limiting at first. Over-fetching with unnecessary fields bugged me, and drawing a single screen required 3-4 API calls.

But honestly, development speed was faster with REST. A Swagger doc was enough for frontend-backend communication, and error tracing was straightforward. Just look at the HTTP status code.

Project three: using both selectively

On the third project, we used both. Main CRUD operations went through REST, while screens like dashboards that needed to aggregate multiple resources at once used GraphQL. It's called the BFF (Backend for Frontend) pattern, and it was the most pragmatic approach.

The tradeoff was increased complexity. Managing two patterns simultaneously bumped new team member onboarding time by 1.5x.

Not really a conclusion, but

Small team where frontend and backend are the same people -- GraphQL is productive. Larger team with separated roles -- REST has lower communication overhead. Dashboard with lots of data aggregation -- GraphQL fits. Simple CRUD -- REST fits.

But in practice, the team's existing experience matters more than project characteristics. If someone knows GraphQL, you use GraphQL. If not, REST. That's the reality of technology choices.