What’s the best choice for an internal reporting API: REST or GraphQL?

[MadisonUW]

I’m trying to decide between using a RESTful design or GraphQL for a new internal reporting API, and I’m stuck on how to handle future changes without breaking existing integrations. The REST endpoints feel rigid, but I’m worried about the complexity of managing a single GraphQL endpoint’s performance and authorization as the schema grows.

[Brian_S]

Been there. REST started to feel rigid when new reports were added. We kept old integrations alive with a deprecation window and a versioned catalog, but every fresh report meant another endpoint and more surface to maintain. Our compromise was a governance doc and using query params for common ad hoc needs instead of new endpoints. It buys time but the brittleness remains.

[JoshuaD]

GraphQL helped unify things but the costs showed up fast. One endpoint, fierce complexity, and a mess around authorization. We used persisted queries, depth limits, and per field checks, plus a gateway to compose schemas. Caching was tricky and monitoring revealed hot paths. We finally split: GraphQL for internal analytics, REST for stable data, and kept expectations bounded.

[ChloeCJ]

From a junior engineer view it felt great at first then slow. We hit N plus 1 in resolvers, even with DataLoader it wandered. It was hard to reason about performance, and auth rules across fields tangled. We added tracing and explicit cost budgets per query, but it was a maintenance burden. We ended up backing off on some features.

[AbigailJ]

Maybe the real problem is elsewhere. Data sources and quality, ETL cadence, and governance; API style is a symptom. We did a small pilot to see how dashboards actually use the API and found bottlenecks in data readiness, not surface. We built a data catalog and a few shared metrics, then revisited the design. Is the issue really how we expose data or how we govern it?