5 ms·

I maintain a relatively big REST API. There are hundreds of different entities with very deep relationships. Our solution is exactly like Stripe's. Clients ask

I maintain a relatively big REST API. There are hundreds of different entities with very deep relationships. 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?

exogen 8y ago
Just FYI, you can query GraphQL with cURL, too. It's just HTTP, it doesn't require any fancy special clients. `fetch` in the browser works fine for talking to GraphQL as well.
- kevincennis 8y ago
  That’s literally true, but on balance it’s way easier to use curl for GET requests to a REST API than it is to use curl for GraphQL queries. At least if we’re talking about “let me curl that route real quick to see what the data looks like”.
  - joshribakoff 8y ago
    You could have a REST API that requires 100s of query params to get at some simple data, or a graphQL API which exposes complex data serialized into a single field. Both can be as easy or as hard to query as you want them to be.
phaedryx 8y ago
Do you consume the API as well? 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.
i_s 8y ago
The standard arguments for GraphQL all apply here. It: - 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
tango12 8y ago
I think the big (only?) advantage that GraphQL has in this case is you get "API documentation" out of the box as a frontend developer. 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?
- emilsedgh 8y ago
  https://docs.rechat.com https://docs.rechat.com 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?
sbr464 8y ago
I think a good reason is developers/users don’t have to learn the verbiage/tooling that each vendor uses, especially for more complex rest APIs that offer features like the fields query param.

exogen 8y ago

Just FYI, you can query GraphQL with cURL, too. It's just HTTP, it doesn't require any fancy special clients. `fetch` in the browser works fine for talking to GraphQL as well.

kevincennis 8y ago
That’s literally true, but on balance it’s way easier to use curl for GET requests to a REST API than it is to use curl for GraphQL queries. At least if we’re talking about “let me curl that route real quick to see what the data looks like”.
- joshribakoff 8y ago
  You could have a REST API that requires 100s of query params to get at some simple data, or a graphQL API which exposes complex data serialized into a single field. Both can be as easy or as hard to query as you want them to be.

phaedryx 8y ago

Do you consume the API as well? 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.

i_s 8y ago

The standard arguments for GraphQL all apply here. It: - 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

tango12 8y ago

I think the big (only?) advantage that GraphQL has in this case is you get "API documentation" out of the box as a frontend developer. 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?

emilsedgh 8y ago
https://docs.rechat.com https://docs.rechat.com 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?

sbr464 8y ago

I think a good reason is developers/users don’t have to learn the verbiage/tooling that each vendor uses, especially for more complex rest APIs that offer features like the fields query param.