4 ms·

GraphQL so far to me just seems like a way to facilitate freedom to front-end engineering in terms of not begin dependent on the back-end when query-ing; I imag

GraphQL so far to me just seems like a way to facilitate freedom to front-end engineering in terms of not begin dependent on the back-end when query-ing; I image that when back- and front-end teams are separate that it can be frustrating to front-enders to wait for the api developers to have made something available to them. At the same time I can see that it works in the other way around; back-end engineers don't have to keep up with changing query requirements from the front-end team. The same is suggested in the article and confirmed in the response to the only comment: "The point is that most APIs end up having to support lots of different client requirements all at the same time... and then those requirements change... and then they change again. You don't want to have "fix" your API every time this happens. GraphQL would support a lot of these differing requirements with no changes to the server code at all." "You don't want to have "fix" your API every time this happens." I don't see why not. Requirements change thus code changes, its not a big deal. The sacrifice you make with this 'not having to change the server side code' is that you are never able to change the server side code again without risking that you take away functionality that is somehow used by some client somewhere. I say 'somehow' because with REST there is usually an endpoint that is either used or not, but with GraphQL there are relations that get used through each other which is less straightforward to determine when pruning or updating your API. It all depends who you are though. For Github it is probably a good idea to provide a GraphQL API as this freedom in the front-end will make adoption of their API and thus their service more likely. If you are a normal company and you are the only consumer of your API I highly question the added benefit. I might be wrong though, so if anyone could point me at some high quality resources on the benefit of GraphQL I am very interested. This article wasn't really that.

tgasson 9y ago
> with GraphQL there are relations that get used through each other which is less straightforward to determine when pruning or updating your API That can be easier since you can add metrics to each individual field rather than url, allowing you to deprecate rarely used fields knowing what you'll break and alert only those who are using it of the change
- le-mark 9y ago
  Is this "adding of metrics" to fields part of graphql api, or something the data store would provide? Apologies but I've only just started exploring graphql.
  - tgasson 9y ago
    No, not part of graphql. Apollo Optics (no relation) is an option, or you can instrument the fields yourself just like you would implement any other instrumentation.
- mosselman 9y ago
  That could be true, but field would not be enough, at least in my limited understanding. I can imagine that I'd also want to know which information is retrieved through other pieces of information. So lets say `Post -> Comments -> Author -> Avatar`, rather than just `Avatar`. This is important because it shows that whatever I do I should at least support the relation to `Avatar` through `Post -> Comments -> Author`.
gt2 9y ago
> with GraphQL there are relations that get used through each other which is less straightforward to determine when pruning or updating your API Add a new GraphQL version endpoint?
- mosselman 9y ago
  In an ideal world API versions would spawn feature-complete from version to version and older versions would require 0% maintenance, yes, but this is not how the world works. As I said, it could work this way for Github, but not your relatively small SaaS. My point was that investing in these kinds of things might not be for everyone.

tgasson 9y ago

> with GraphQL there are relations that get used through each other which is less straightforward to determine when pruning or updating your API That can be easier since you can add metrics to each individual field rather than url, allowing you to deprecate rarely used fields knowing what you'll break and alert only those who are using it of the change

le-mark 9y ago
Is this "adding of metrics" to fields part of graphql api, or something the data store would provide? Apologies but I've only just started exploring graphql.
- tgasson 9y ago
  No, not part of graphql. Apollo Optics (no relation) is an option, or you can instrument the fields yourself just like you would implement any other instrumentation.
mosselman 9y ago
That could be true, but field would not be enough, at least in my limited understanding. I can imagine that I'd also want to know which information is retrieved through other pieces of information. So lets say `Post -> Comments -> Author -> Avatar`, rather than just `Avatar`. This is important because it shows that whatever I do I should at least support the relation to `Avatar` through `Post -> Comments -> Author`.

gt2 9y ago

> with GraphQL there are relations that get used through each other which is less straightforward to determine when pruning or updating your API Add a new GraphQL version endpoint?

mosselman 9y ago
In an ideal world API versions would spawn feature-complete from version to version and older versions would require 0% maintenance, yes, but this is not how the world works. As I said, it could work this way for Github, but not your relatively small SaaS. My point was that investing in these kinds of things might not be for everyone.