Not the user you were asking, but the way we do it is that the OpenAPI/Swagger spec is auto-generated from server-side code (a C# .NET app with the ABP framework) during the CI build, and that is then used to auto-generate an API client (via swagger-typescript-api) which is what the frontend app uses.

When the backend team makes some changes, they notify the front-end team which then runs the auto-generation script, fixes the typescript errors (if there were breaking changes), and that's it. Pretty nice setup, IMO.

Nice!

Why not re-run the auto-generation script automatically?

We use these types all over the app, manual intervention is very often needed.

We edit the OAS with Stoplight Studio, and enforce it with server-side middleware, which validates that requests and responses conform to the OAS (400s if requests don’t conform, 500s if responses don’t conform).

At a previous workplace I’ve used OpenAPI Generator to generate clients and server stubs from the OAS, which is a nice approach to ensuring you’re confirming to the spec, too.

Did you have the requirements for users that you do not know want to define their own API upon your data?

No, it’s never come up. This is touted as a selling point of GraphQL, but IMO is mostly solving a problem that few people have. Having worked a lot both consuming and producing external APIs, people seem happiest with idiomatic, well documented RESTful APIs, they don’t want to learn some complex RPC system like GraphQL just to use your API.

I think these GQL benefits are somewhat legit:

1. Fetch in one round trip what would take multiple with REST

2. Fetch only the response fields you need

But honestly, 1 generally saves 0-1 round trips, and for 2, while response payloads are smaller, GQL requests payloads tend to be huge, so it’s largely a wash. At least in my GQL usage, they’ve been minor wins, not worth the complexity that GQL adds.