4 ms·

Naive question: Is GraphQL meant to be used only by the frontend developers to consume backend data, etc? And not by the actual consumers of the API (ie custome

Naive question: Is GraphQL meant to be used only by the frontend developers to consume backend data, etc? And not by the actual consumers of the API (ie customers, users)? If not, I don't see why consumers would ever want to use GraphQL. Figuring out the syntax/language to do something as simple as retrieving the first X items requires more thought than calling a dead-simple REST endpoint.

iamjaredwalters 8y ago
> more thought than calling a dead-simple REST endpoint REST shortcomings aren't necessarily found in a single api request. REST's shortcomings are the handful of endpoints required to get the information you actually want.
- dragonwriter 8y ago
  > REST's shortcomings are the handful of endpoints required to get the information you actually want. That's a problem of a naive CRUD API against a normalized relational datastore (or one structurally resembling such a store) regardless of architectural style, but there is no reason any standardized packet of information for which there is an expected recurring need should not be conceptualized as a resource in a REST API. Orthogonality or normalization is not part of the REST architectural style.
  - jonreem 8y ago
    This approach necessitates an ever growing number of increasingly specific APIs, or an ever growing set of flags and options which will inevitably approximate a poorly implemented version of GraphQL.
    - iamjaredwalters 8y ago
      Exactly. Eventually eroding REST away to "RESTful".
dwwoelfel 8y ago
> Figuring out the syntax/language to do something as simple as retrieving the first X items requires more thought than calling a dead-simple REST endpoint. I'm obviously biased as one of the founders of OneGraph. There's a one-time cost of learning the syntax (which we're trying to make easier!), but once you've done that my experience is that it's easier to use a GraphQL endpoint from the backend than a REST endpoint. We used Facebook's GraphQL endpoint from a Clojure backend when I joined the Wit team after they were acquired. It was very handy to be able to look at the query and have a general idea of the data that was going to be returned rather than inspect a response or look up the docs.
the_duke 8y ago
GraphQL is definitely much more complicated to use for users than a REST api, which is the well known standard for everyone. For complex APIs that are used by consumers for many tasks, it can make sense though. If you are using GraphQL internally, you might as well expose a version of it to customers. See for example Github, which has a GraphQL API.
- fiddlerwoaroof 8y ago
  "standard": random endpoints returning JSON can be easy to use, once you're familiar with them, but you have to learn each endpoint separately. Hopefully GraphQL (or something like JSONAPI) will bring us a real standard interface to apis.
  - sgrove 8y ago
    There's also openapi [1], but there's a real social/process challenge in keeping it in sync with the actual implementation. The tools that build on it are great, but there's a lot of surface area to cover when bolting on computer-understanding to an existing api. GraphQL's approach of mandating introspection means more work in some areas, and far less in others. Searching for the data available in a REST api can be a big issue, for example, depending on the state of the documentation.
sl1ck731 8y ago
The biggest benefit for me is that since I'm working on both ends of the stack I don't constantly have to make little changes on the backend to accomplish what I want on the frontend. In the past I've ended up with an array of alternative endpoints using different methods or query parameters for special cases whereas now the particulars about what I want to retrieve is more delegated to what I'm doing on the frontend. It is also quicker in that I don't have to write client libraries as I go. Even more, now I'm using postgrahile and don't even bother with writing the backend for much of anything except special case resolvers. This has increased my productive time but it might not be a fit for everyone. The nice thing is that I keep my schema in the app repo and have the entire thing provisioned from 1 script. If I need a new resource I just modify the database schema and the graphql resolvers are created automatically.
yen223 8y ago
Calling an endpoint is only half the story. You still need to know the shape of the response. And most rest APIs I've had to use do a suboptimal job at communicating the schema of the response. Even Stripe's API, which is far ahead of most other APIs in terms of documentation, doesn't tell you basic things like whether a field can ever be null. GraphQL defines an interface for describing the schema of an endpoint. This to me is the most valuable thing about it.
- sgrove 8y ago
  This is a great point - Stripe is one of the exceptional companies that maintains a great openapi spec though! Even so, the GraphQL experience (with the explorer and some other OSS releases we have for next week) is still just so exciting https://serve.onegraph.com/short/Q8SE4F https://serve.onegraph.com/short/Q8SE4F :D query search { stripe { invoices(first: 10) { nodes { amountDue nextPaymentAttempt object total customer { ... on StripeCustomer { id email } } charge { dispute { created reason status } } } } } } - Type (and nullability!) of fields - In-situ documentation on what the fields are for - Ability to navigate the Stripe graph from any starting point (customer -> charges -> cards) in a single super-efficient call - Search-ability across the whole Stripe API in a single field - Potentially joins across services, e.g. from Stripe to Zendesk or Salesforce And so on and so on!
atombender 8y ago
I think GraphQL is absolutely suitable for being exposed as a public API. Given a schema, it's arguably simpler to write clients than with REST, where every API is completely ad-hoc with respect to how you pass parameters, paginate, select which fields (including nested data) you want, etc. I think the more interesting question is whether GraphQL is a suitable inter-application API foundation. In many ways it aligns better with application requirements than gRPC. gRPC is even farther away from REST, with limited abilities to do field selection and no inherent support for nesting. And gRPC needs special help to work in browsers. What gRPC has is a compact serialization format and a toolchain that encourages using Protobuf structs for your own internals. When implementing an app, it certainly seems redundant to offer both GraphQL and gRPC.
- sgrove 8y ago
  I suspect that GraphQL is largely is superset of gRPC, but that gRPC can go places unsuitable for GraphQL as it exists today. Nothing about GraphQL prevents using e.g. protobufs in theory, but in practice 99.99+% expect to send/receive son.

iamjaredwalters 8y ago

> more thought than calling a dead-simple REST endpoint REST shortcomings aren't necessarily found in a single api request. REST's shortcomings are the handful of endpoints required to get the information you actually want.

dragonwriter 8y ago
> REST's shortcomings are the handful of endpoints required to get the information you actually want. That's a problem of a naive CRUD API against a normalized relational datastore (or one structurally resembling such a store) regardless of architectural style, but there is no reason any standardized packet of information for which there is an expected recurring need should not be conceptualized as a resource in a REST API. Orthogonality or normalization is not part of the REST architectural style.
- jonreem 8y ago
  This approach necessitates an ever growing number of increasingly specific APIs, or an ever growing set of flags and options which will inevitably approximate a poorly implemented version of GraphQL.
  - iamjaredwalters 8y ago
    Exactly. Eventually eroding REST away to "RESTful".

dwwoelfel 8y ago

> Figuring out the syntax/language to do something as simple as retrieving the first X items requires more thought than calling a dead-simple REST endpoint. I'm obviously biased as one of the founders of OneGraph. There's a one-time cost of learning the syntax (which we're trying to make easier!), but once you've done that my experience is that it's easier to use a GraphQL endpoint from the backend than a REST endpoint. We used Facebook's GraphQL endpoint from a Clojure backend when I joined the Wit team after they were acquired. It was very handy to be able to look at the query and have a general idea of the data that was going to be returned rather than inspect a response or look up the docs.

the_duke 8y ago

GraphQL is definitely much more complicated to use for users than a REST api, which is the well known standard for everyone. For complex APIs that are used by consumers for many tasks, it can make sense though. If you are using GraphQL internally, you might as well expose a version of it to customers. See for example Github, which has a GraphQL API.

fiddlerwoaroof 8y ago
"standard": random endpoints returning JSON can be easy to use, once you're familiar with them, but you have to learn each endpoint separately. Hopefully GraphQL (or something like JSONAPI) will bring us a real standard interface to apis.
- sgrove 8y ago
  There's also openapi [1], but there's a real social/process challenge in keeping it in sync with the actual implementation. The tools that build on it are great, but there's a lot of surface area to cover when bolting on computer-understanding to an existing api. GraphQL's approach of mandating introspection means more work in some areas, and far less in others. Searching for the data available in a REST api can be a big issue, for example, depending on the state of the documentation.

sl1ck731 8y ago

The biggest benefit for me is that since I'm working on both ends of the stack I don't constantly have to make little changes on the backend to accomplish what I want on the frontend. In the past I've ended up with an array of alternative endpoints using different methods or query parameters for special cases whereas now the particulars about what I want to retrieve is more delegated to what I'm doing on the frontend. It is also quicker in that I don't have to write client libraries as I go. Even more, now I'm using postgrahile and don't even bother with writing the backend for much of anything except special case resolvers. This has increased my productive time but it might not be a fit for everyone. The nice thing is that I keep my schema in the app repo and have the entire thing provisioned from 1 script. If I need a new resource I just modify the database schema and the graphql resolvers are created automatically.

yen223 8y ago

Calling an endpoint is only half the story. You still need to know the shape of the response. And most rest APIs I've had to use do a suboptimal job at communicating the schema of the response. Even Stripe's API, which is far ahead of most other APIs in terms of documentation, doesn't tell you basic things like whether a field can ever be null. GraphQL defines an interface for describing the schema of an endpoint. This to me is the most valuable thing about it.

sgrove 8y ago
This is a great point - Stripe is one of the exceptional companies that maintains a great openapi spec though! Even so, the GraphQL experience (with the explorer and some other OSS releases we have for next week) is still just so exciting https://serve.onegraph.com/short/Q8SE4F https://serve.onegraph.com/short/Q8SE4F :D query search { stripe { invoices(first: 10) { nodes { amountDue nextPaymentAttempt object total customer { ... on StripeCustomer { id email } } charge { dispute { created reason status } } } } } } - Type (and nullability!) of fields - In-situ documentation on what the fields are for - Ability to navigate the Stripe graph from any starting point (customer -> charges -> cards) in a single super-efficient call - Search-ability across the whole Stripe API in a single field - Potentially joins across services, e.g. from Stripe to Zendesk or Salesforce And so on and so on!

atombender 8y ago

I think GraphQL is absolutely suitable for being exposed as a public API. Given a schema, it's arguably simpler to write clients than with REST, where every API is completely ad-hoc with respect to how you pass parameters, paginate, select which fields (including nested data) you want, etc. I think the more interesting question is whether GraphQL is a suitable inter-application API foundation. In many ways it aligns better with application requirements than gRPC. gRPC is even farther away from REST, with limited abilities to do field selection and no inherent support for nesting. And gRPC needs special help to work in browsers. What gRPC has is a compact serialization format and a toolchain that encourages using Protobuf structs for your own internals. When implementing an app, it certainly seems redundant to offer both GraphQL and gRPC.

sgrove 8y ago
I suspect that GraphQL is largely is superset of gRPC, but that gRPC can go places unsuitable for GraphQL as it exists today. Nothing about GraphQL prevents using e.g. protobufs in theory, but in practice 99.99+% expect to send/receive son.