4 ms·

I've found GraphQL to greatly improve the developer experience when building web apps. As a front-end developer you can easily get a full view of the data and

I've found GraphQL to greatly improve the developer experience when building web apps. As a front-end developer you can easily get a full view of the data and relationships. Tools like GraphiQL make exploring APIs a pleasure. And regardless of what you need to present to the user on screen, you can quickly build a request that perfectly matches the data you need. There is also the nice addition of strict typing and there are libraries that automatically generate TypeScript types for you from the schema and/or your operations.

jamil7 6y ago
I don't have especially strong feelings either way, but the majority of this is possible with OpenAPI as well.
kristaps 6y ago
I would like a backend developer perspective on the same. I haven't done any GraphQL stuff myself, but the "I can get whatever data I need" aspect feels like a huge potential headache for backend devs. Won't be a problem at prototype scale, but once you have a significant client count, how do you deal with unpredictable data access patterns that can't be optimized ahead of time?
- mikecaulley 6y ago
  Generally speaking, it's not more difficult than creating a REST API controller. Rather than mapping your service code to a controller, you map it to a (GraphQL) resolver. It feels extremely similar. There are different things to look out for; like handling n+1 (https://shopify.engineering/solving-the-n-1-problem-for-graphql-through-batching https://shopify.engineering/solving-the-n-1-problem-for-grap...) queries, but nothing that I can say is too difficult.
  - dmitriid 6y ago
    It is more difficult. With REST you know ahead of time which data you need, and you can optimise it as much as you can. With GraphQL at any given point in time you have no idea what the request is. Dataloaders solve it to some extent, but not much.
    - mikecaulley 6y ago
      Of course, you are building something that is much more powerful. If you intend every possible GraphQL operation to perform perfectly, it'll take more development effort. Though if you optimize for only the most likely cases, the effort is not much greater.
      - dmitriid 6y ago
        > Though if you optimize for only the most likely cases, the effort is not much greater. That's why most discussions involving complexities of GraphQL inevitably devolve into: "in production we only allow a subset of queries". Because actually implementing GraphQL as it's specified and marketed is quite an undertaking.
- no_wizard 6y ago
  Inevitably you do get a map of your data flow. GraphQL can be a huge help here, because you must have resolvers for the queries. It forces you to think ahead of time about how you're going to resolve getting the data to fulfill the API "contract" if you will. You can optimize that. GraphQL is great for describing your APIs in a type safe(ish) way where you get great decoupling by design. I also will say that since a query can use multiple resolvers, that's where I have found it really shines. The model does implicitly work best when you have async systems over synchronous ones for more complex queries (multithreaded/multiprocess) that's my anecdote, as someone who is currently and actively building and maintaining GraphQL backend services. Its true you can get the same with any API design pattern, really, I will say, however GraphQL has specifications for all this, and I think that's what makes it more powerful Another nice thing, is no versioning. I can just use the `@deprecated` built in directive, and when the usage of a deprecated part of an API gets consistently (for a specified period of time) down to 0, I can just remove it entirely. OpenAPI and the like don't have a descriptive way to notify users of an API of this, you, for better or worse, have to version your API, which often ends up in situations where you always have an old version sticking around for a very long time. Like all technologies though, it can (and does) have its issues. It adds a certain amount of complexity to your applications (more so for the client, IMO, even though exploring APIs is a huge upside with tools like GraphiQL)
criddell 6y ago
To what extent are you just pushing complexity to the back-end developers? > Tools like GraphiQL make exploring APIs a pleasure. No argument there. Is there something similar for traditional REST? For some reason, I thought the point of HATEOS was to make that kind of exploration possible.
- hardwaresofton 6y ago
  GraphQL cannot ever be explored in the same way HATEOAS can because it is missing the linking part (and other related technology like JSON-LD). That said, GraphQL does offer introspection[0] which is not a bad start but lacks the breadth an depth of the hyperlink based approaches. [0]: https://graphql.org/learn/introspection/ https://graphql.org/learn/introspection/
  - shoelessone 6y ago
    I 100% agree with your statement. I also realize you are not championing HATEOAS here necessarily. That said, I am curious if you have found this "linking" aspect of HATEOAS useful for actual implementations? I have been doing integration work with a system that strictly adheres to "REST level 3" and "HATEOAS" principles for the past few years, and I myself have found the "explore-ability" of the API super handy. That said, the self-documenting nature only goes so far, and in the end I'm not sure the internal linking stuff is preferable to robust documentation. I'm not trying to be down on this necessarily, I actually generally push back on the adoption of GraphQL as the answer to every problem.
    - hardwaresofton 6y ago
      > That said, I am curious if you have found this "linking" aspect of HATEOAS useful for actual implementations? I have been doing integration work with a system that strictly adheres to "REST level 3" and "HATEOAS" principles for the past few years, and I myself have found the "exploitability" of the API super handy. That said, the self-documenting nature only goes so far, and in the end I'm not sure the internal linking stuff is preferable to robust documentation. You're right, this is a reasonable question and the answer is uncomfortable. I personally find it useful when paired with OpenAPI -- generally by using annotations on controllers and models, but it is indeed rare to have usecases that fit the linking functionality well enough to be significantly better than what you would get from just good documentation. The "killer app" of this space for me personally is a Django Admin[0][1] (or React-Admin[2]) clone that is 100% client-side automated. I don't have a demo yet, but once I do it'll be up on HN. > I'm not trying to be down on this necessarily, I actually generally push back on the adoption of GraphQL as the answer to every problem. Please, feel free to push back, that's what discussion is for, and ideas that can't stand up to push back probably shouldn't be adopted. [0]: https://docs.djangoproject.com/en/3.1/ref/contrib/admin/# https://docs.djangoproject.com/en/3.1/ref/contrib/admin/# [1]: https://djangobook.com/mdj2-django-admin/ https://djangobook.com/mdj2-django-admin/ [2]: https://github.com/marmelab/react-admin https://github.com/marmelab/react-admin
hardwaresofton 6y ago
I do agree that GraphQL has improved developer experience, or at the very least improved the perceived experience (which is essentially the same as actually improving the experience). I cannot deny it's popularity, and that comes from hype along with usefulness (perceived or actual). > Tools like GraphiQL make exploring APIs a pleasure. This is an innovation of the developers of GraphiQL, not of GraphQL itself. It's possible to build IDE support similar ot that of GraphiQL, with the rich metadata and schema data that is available by design in OpenAPI + JSONSchema + JSON-LD + HATEOAS land. The problem is that no one did/was excited enough to, the slog from Swagger2 to OpenAPI3 might have sapped the enthusiasm of the community just enough (or the emergence of GraphQL), but it's not that the tools isn't possible with other approaches. > There is also the nice addition of strict typing and there are libraries that automatically generate TypeScript types for you from the schema and/or your operations. This was already present with OpenAPI and related tools, so I personally don't put this as something that GraphQL brought about.
- serverholic 6y ago
  I don't want to piece together 4 different technologies to get the same thing. And it's not even the same thing. You keep mentioning HATEOAS but that doesn't accomplish the same things as graphql at all. With HATEOAS I need to send out multiple requests to collect the data I need. With graphql I can send out one request to retrieve exactly the data I need. I can also combine multiple requests into a single request. GraphQL also only retrieves the fields you need by default. This is something you'd need to build manually with REST. And yes, reducing the number of server requests does matter when you're trying to optimize for the largest market possible. Including people on slow mobile network connections where every request adds significant overhead.
  - hardwaresofton 6y ago
    > I don't want to piece together 4 different technologies to get the same thing. > And it's not even the same thing. You keep mentioning HATEOAS but that doesn't accomplish the same things as graphql at all. With HATEOAS I need to send out multiple requests to collect the data I need. With graphql I can send out one request to retrieve exactly the data I need. I can also combine multiple requests into a single request. GraphQL also only retrieves the fields you need by default. This is something you'd need to build manually with REST. All of this is reasonable, but my point was that we've abandoned a more flexible method, that had composable functionality and agreed-upon standards for GraphQL. You gained some pipelining, and some vertical filtering, but threw out a lot with the bathwater. GraphQL does give you a way to do these things, and this is why it is popular (or at least a good reason why), but it is missing the wider possibilities of the other ecosystem. As people start to try and abstract over it they will be abstracting over a less robust, considered, standardized base. > And yes, reducing the number of server requests does matter when you're trying to optimize for the largest market possible. Including people on slow mobile network connections where every request adds significant overhead. Reducing the number of server requests does indeed matter -- I did not mean to propose it doesn't, reducing request was somewhat solved before now with the backend-for-frontend approach. There are lots of approaches to help people on slow mobile network connections, but the ultimate one is to server-render and trim as much as possible -- I'm not sure GraphQL is much better at this than REST with efficient endpoint choice.

jamil7 6y ago

I don't have especially strong feelings either way, but the majority of this is possible with OpenAPI as well.

kristaps 6y ago

I would like a backend developer perspective on the same. I haven't done any GraphQL stuff myself, but the "I can get whatever data I need" aspect feels like a huge potential headache for backend devs. Won't be a problem at prototype scale, but once you have a significant client count, how do you deal with unpredictable data access patterns that can't be optimized ahead of time?

mikecaulley 6y ago
Generally speaking, it's not more difficult than creating a REST API controller. Rather than mapping your service code to a controller, you map it to a (GraphQL) resolver. It feels extremely similar. There are different things to look out for; like handling n+1 (https://shopify.engineering/solving-the-n-1-problem-for-graphql-through-batching https://shopify.engineering/solving-the-n-1-problem-for-grap...) queries, but nothing that I can say is too difficult.
- dmitriid 6y ago
  It is more difficult. With REST you know ahead of time which data you need, and you can optimise it as much as you can. With GraphQL at any given point in time you have no idea what the request is. Dataloaders solve it to some extent, but not much.
  - mikecaulley 6y ago
    Of course, you are building something that is much more powerful. If you intend every possible GraphQL operation to perform perfectly, it'll take more development effort. Though if you optimize for only the most likely cases, the effort is not much greater.
    - dmitriid 6y ago
      > Though if you optimize for only the most likely cases, the effort is not much greater. That's why most discussions involving complexities of GraphQL inevitably devolve into: "in production we only allow a subset of queries". Because actually implementing GraphQL as it's specified and marketed is quite an undertaking.
no_wizard 6y ago
Inevitably you do get a map of your data flow. GraphQL can be a huge help here, because you must have resolvers for the queries. It forces you to think ahead of time about how you're going to resolve getting the data to fulfill the API "contract" if you will. You can optimize that. GraphQL is great for describing your APIs in a type safe(ish) way where you get great decoupling by design. I also will say that since a query can use multiple resolvers, that's where I have found it really shines. The model does implicitly work best when you have async systems over synchronous ones for more complex queries (multithreaded/multiprocess) that's my anecdote, as someone who is currently and actively building and maintaining GraphQL backend services. Its true you can get the same with any API design pattern, really, I will say, however GraphQL has specifications for all this, and I think that's what makes it more powerful Another nice thing, is no versioning. I can just use the `@deprecated` built in directive, and when the usage of a deprecated part of an API gets consistently (for a specified period of time) down to 0, I can just remove it entirely. OpenAPI and the like don't have a descriptive way to notify users of an API of this, you, for better or worse, have to version your API, which often ends up in situations where you always have an old version sticking around for a very long time. Like all technologies though, it can (and does) have its issues. It adds a certain amount of complexity to your applications (more so for the client, IMO, even though exploring APIs is a huge upside with tools like GraphiQL)

criddell 6y ago

To what extent are you just pushing complexity to the back-end developers? > Tools like GraphiQL make exploring APIs a pleasure. No argument there. Is there something similar for traditional REST? For some reason, I thought the point of HATEOS was to make that kind of exploration possible.

hardwaresofton 6y ago
GraphQL cannot ever be explored in the same way HATEOAS can because it is missing the linking part (and other related technology like JSON-LD). That said, GraphQL does offer introspection[0] which is not a bad start but lacks the breadth an depth of the hyperlink based approaches. [0]: https://graphql.org/learn/introspection/ https://graphql.org/learn/introspection/
- shoelessone 6y ago
  I 100% agree with your statement. I also realize you are not championing HATEOAS here necessarily. That said, I am curious if you have found this "linking" aspect of HATEOAS useful for actual implementations? I have been doing integration work with a system that strictly adheres to "REST level 3" and "HATEOAS" principles for the past few years, and I myself have found the "explore-ability" of the API super handy. That said, the self-documenting nature only goes so far, and in the end I'm not sure the internal linking stuff is preferable to robust documentation. I'm not trying to be down on this necessarily, I actually generally push back on the adoption of GraphQL as the answer to every problem.
  - hardwaresofton 6y ago
    > That said, I am curious if you have found this "linking" aspect of HATEOAS useful for actual implementations? I have been doing integration work with a system that strictly adheres to "REST level 3" and "HATEOAS" principles for the past few years, and I myself have found the "exploitability" of the API super handy. That said, the self-documenting nature only goes so far, and in the end I'm not sure the internal linking stuff is preferable to robust documentation. You're right, this is a reasonable question and the answer is uncomfortable. I personally find it useful when paired with OpenAPI -- generally by using annotations on controllers and models, but it is indeed rare to have usecases that fit the linking functionality well enough to be significantly better than what you would get from just good documentation. The "killer app" of this space for me personally is a Django Admin[0][1] (or React-Admin[2]) clone that is 100% client-side automated. I don't have a demo yet, but once I do it'll be up on HN. > I'm not trying to be down on this necessarily, I actually generally push back on the adoption of GraphQL as the answer to every problem. Please, feel free to push back, that's what discussion is for, and ideas that can't stand up to push back probably shouldn't be adopted. [0]: https://docs.djangoproject.com/en/3.1/ref/contrib/admin/# https://docs.djangoproject.com/en/3.1/ref/contrib/admin/# [1]: https://djangobook.com/mdj2-django-admin/ https://djangobook.com/mdj2-django-admin/ [2]: https://github.com/marmelab/react-admin https://github.com/marmelab/react-admin

hardwaresofton 6y ago

I do agree that GraphQL has improved developer experience, or at the very least improved the perceived experience (which is essentially the same as actually improving the experience). I cannot deny it's popularity, and that comes from hype along with usefulness (perceived or actual). > Tools like GraphiQL make exploring APIs a pleasure. This is an innovation of the developers of GraphiQL, not of GraphQL itself. It's possible to build IDE support similar ot that of GraphiQL, with the rich metadata and schema data that is available by design in OpenAPI + JSONSchema + JSON-LD + HATEOAS land. The problem is that no one did/was excited enough to, the slog from Swagger2 to OpenAPI3 might have sapped the enthusiasm of the community just enough (or the emergence of GraphQL), but it's not that the tools isn't possible with other approaches. > There is also the nice addition of strict typing and there are libraries that automatically generate TypeScript types for you from the schema and/or your operations. This was already present with OpenAPI and related tools, so I personally don't put this as something that GraphQL brought about.

serverholic 6y ago
I don't want to piece together 4 different technologies to get the same thing. And it's not even the same thing. You keep mentioning HATEOAS but that doesn't accomplish the same things as graphql at all. With HATEOAS I need to send out multiple requests to collect the data I need. With graphql I can send out one request to retrieve exactly the data I need. I can also combine multiple requests into a single request. GraphQL also only retrieves the fields you need by default. This is something you'd need to build manually with REST. And yes, reducing the number of server requests does matter when you're trying to optimize for the largest market possible. Including people on slow mobile network connections where every request adds significant overhead.
- hardwaresofton 6y ago
  > I don't want to piece together 4 different technologies to get the same thing. > And it's not even the same thing. You keep mentioning HATEOAS but that doesn't accomplish the same things as graphql at all. With HATEOAS I need to send out multiple requests to collect the data I need. With graphql I can send out one request to retrieve exactly the data I need. I can also combine multiple requests into a single request. GraphQL also only retrieves the fields you need by default. This is something you'd need to build manually with REST. All of this is reasonable, but my point was that we've abandoned a more flexible method, that had composable functionality and agreed-upon standards for GraphQL. You gained some pipelining, and some vertical filtering, but threw out a lot with the bathwater. GraphQL does give you a way to do these things, and this is why it is popular (or at least a good reason why), but it is missing the wider possibilities of the other ecosystem. As people start to try and abstract over it they will be abstracting over a less robust, considered, standardized base. > And yes, reducing the number of server requests does matter when you're trying to optimize for the largest market possible. Including people on slow mobile network connections where every request adds significant overhead. Reducing the number of server requests does indeed matter -- I did not mean to propose it doesn't, reducing request was somewhat solved before now with the backend-for-frontend approach. There are lots of approaches to help people on slow mobile network connections, but the ultimate one is to server-render and trim as much as possible -- I'm not sure GraphQL is much better at this than REST with efficient endpoint choice.