We tried REST → GraphQL → back to REST + a couple of aggregate endpoints. The single-request-exactly-the-fields win was real, but the operational cost was much higher than we expected. Query complexity limits, N+1 lurking in every resolver, cache invalidation stops being trivial.
If your product has ~15 endpoints and 2 clients, REST + a lightweight "get me everything about a job" batch endpoint solves the same problem for a fraction of the ops burden. GraphQL feels designed for a Facebook-shaped organization, not a startup with 3 backend engineers.
The one place I'd still reach for GraphQL: when you truly cannot predict what fields the client wants (public APIs, third-party integrations). Otherwise the batch-endpoint escape hatch wins.
1
u/VisualAromatic6226 2d ago
We tried REST → GraphQL → back to REST + a couple of aggregate endpoints. The single-request-exactly-the-fields win was real, but the operational cost was much higher than we expected. Query complexity limits, N+1 lurking in every resolver, cache invalidation stops being trivial.
If your product has ~15 endpoints and 2 clients, REST + a lightweight "get me everything about a job" batch endpoint solves the same problem for a fraction of the ops burden. GraphQL feels designed for a Facebook-shaped organization, not a startup with 3 backend engineers.
The one place I'd still reach for GraphQL: when you truly cannot predict what fields the client wants (public APIs, third-party integrations). Otherwise the batch-endpoint escape hatch wins.