Our solution is exactly like Stripe's. Clients ask for the relationships they want to fetch using the query string.
It's not ideal. Seems like a hack. But it works.
On the bright side, I can query the system using curl.
What should be my incentive to consider switching to GraphQL for this project?
What should be my incentive to consider GraphQL for my next project?
The tradeoff is that I need to use GraphiQL or similar tooling to leverage this auto-complete, type-safe magic and that using curl becomes more painful.
I'm curious: Suppose you converted your REST endpoints into GraphQL endpoints in the simplest way possible by changing the query-params to root GraphQL nodes. So there's no "graph" really. Just lots of top level nodes. This reduces the API docs overhead and nothing else.
Would you switch? Is your existing tooling to extract API docs already good enough that this isn't a problem?
This is our API Documentation and it's generated automatically from our E2E tests. It's almost free for us to maintain.
Can you tell me if this is OK enough comparing to a GraphQL that wouldn't justify a rewrite?
I'm currently writing the GraphQL API to replace our REST API. It is a lot of work, but when I have to put on my "front-end" hat it will be much easier to work with. I think the biggest payoff is for consumers.
- Lets you send only the information asked for. For example, you may be sending 50 fields when the client is only interested in 2.
- Lets you evolve the API more safely
- Enables better tooling for people who need to explore your API, like GraphiQL