15 ms·

Yeah my first encounter with GraphQL was a client going "let's save development time by using graphql!" so I looked into it and it's more fucking work unless yo

Yeah my first encounter with GraphQL was a client going "let's save development time by using graphql!" so I looked into it and it's more fucking work unless your stack has one of those auto-GraphQL-to-and-from-DB generators (they'd made a poor and somewhat obscure choice of DB for the project, over our advice, so there wasn't such a thing in this case anyway) and it happens to suit your needs very well—and even with the benefit of one of those I'd still lose sleep over security or DoS bugs lurking in that 3rd party code. Or in mine.

shakezula 7y ago
The cases where GraphQL make sense are the ones where the front end is making tons of intricate, complicated calls. If it’s a simple REST api you’re interacting with it probably doesn’t need GraphQL and might actually be harmed by it.
- ldng 7y ago
  GraphQL is only interesting for flexibility to fast prototyping/changes on the client side, to me. And it should stay there. Meaning your client JS should have a data layer that can understand GraphQL and translate that to a REST API call and cache the result.
bernawil 7y ago
The only extra work compared to REST is writing your query and mutations input and output types. But since any serious REST API nowadays includes swagger, it's actually even if not worse on REST. Then it's all the same as of how much work. In the server, each REST endpoint is a gql resolver. As of auto-generation regards: yes, gql maps great to a relational model, so you can save a lot of effort going that route. But you know, there's auto-generation for REST setups too.
- cuddlecake 7y ago
  - Swagger is not the only API Spec framework. I think rather than serious REST APIs having Swagger, good APIs have (auto-generated) client libs. - in REST, you have no default way of querying data related to the current path. Of course, you can use frameworks for that (filtering, hydrating references, etc.). In GraphQL, you have entry queries and the rest is graph traversal, and that is basically the default (and of course, it does come with its disadvantages) - on auto-generated schema: the interesting thing here is not whether you have auto-generated schemas etc. at all, but how well the data relations can be surfaced, explored and accessed on the API level. GraphQL enabled this in a different way compared to REST, and I would dare say it is a more delightful way. As a client, given a Swagger API Documentation and a GraphQL Schema, I would prefer exploring the GraphQL Schema, just to find out what the API is about.
  - deleted 7y ago
    [deleted]
  - shakezula 7y ago
    > auto-generated client libs I agree with this. Working with protobuf and generating the TS/PB files for the client/browser on a Go project felt like this. With some better tooling around that I think it would be a really slick development environment.

shakezula 7y ago

The cases where GraphQL make sense are the ones where the front end is making tons of intricate, complicated calls. If it’s a simple REST api you’re interacting with it probably doesn’t need GraphQL and might actually be harmed by it.

ldng 7y ago
GraphQL is only interesting for flexibility to fast prototyping/changes on the client side, to me. And it should stay there. Meaning your client JS should have a data layer that can understand GraphQL and translate that to a REST API call and cache the result.

bernawil 7y ago

The only extra work compared to REST is writing your query and mutations input and output types. But since any serious REST API nowadays includes swagger, it's actually even if not worse on REST. Then it's all the same as of how much work. In the server, each REST endpoint is a gql resolver. As of auto-generation regards: yes, gql maps great to a relational model, so you can save a lot of effort going that route. But you know, there's auto-generation for REST setups too.

cuddlecake 7y ago
- Swagger is not the only API Spec framework. I think rather than serious REST APIs having Swagger, good APIs have (auto-generated) client libs. - in REST, you have no default way of querying data related to the current path. Of course, you can use frameworks for that (filtering, hydrating references, etc.). In GraphQL, you have entry queries and the rest is graph traversal, and that is basically the default (and of course, it does come with its disadvantages) - on auto-generated schema: the interesting thing here is not whether you have auto-generated schemas etc. at all, but how well the data relations can be surfaced, explored and accessed on the API level. GraphQL enabled this in a different way compared to REST, and I would dare say it is a more delightful way. As a client, given a Swagger API Documentation and a GraphQL Schema, I would prefer exploring the GraphQL Schema, just to find out what the API is about.
- deleted 7y ago
  [deleted]
- shakezula 7y ago
  > auto-generated client libs I agree with this. Working with protobuf and generating the TS/PB files for the client/browser on a Go project felt like this. With some better tooling around that I think it would be a really slick development environment.