6 ms·

> A GraphQL API (server) implementation, out of the box, will have better performance than a standard REST API - for the clients. Since resolvers are called in

> A GraphQL API (server) implementation, out of the box, will have better performance than a standard REST API - for the clients. Since resolvers are called in parallel, data will load faster. What does this mean? Are these theoretical REST endpoints fetching information serially, or something? Almost all of our REST endpoints fetch all of their information in a single hand-optimized SQL query. How is GraphQL going to run faster than that?

tango12 8y ago
This. Exactly this! I think anyone with experience will realise that you can get pretty much all the benefits of GraphQL with just a more sophisticated RESTish API. There is however, one thing that I think GraphQL backends have that REST backends don't, and that's the idea of introspection. Every GraphQL backend must be able to serve it's API data models and types. And I think the community tooling that leverages this makes it an amazing experience for app developers. No SDKs, any GraphQL client works with any GraphQL backend. Codegen esp for Android type apps to skip boilerplate of mapping APIs to POJOs. IDE autocomplete. I really think that the killer feature of GraphQL is that. We built a JSON DSL over a normal POST endpoint. Most GraphQL advantages sound "not really true" to me because you can always achieve the same thing (almost) yourself anyway.
- iEchoic 8y ago
  Yup, agreed - the developer experience and the self-documenting nature of GraphQL is a big plus. I no longer use GraphQL, but this is something I miss about it. As you mention though, people often don't realize that GraphQL is just a way to tell an endpoint that you want information in a generic way, and a pattern for having that endpoint resolve information in a generic way. It's an abstraction on top of a normal service call, and like most abstractions, it gives you consistency and ease-of-use but not any new capabilities you didn't have before.
- sixdimensional 8y ago
  Just wanted to chime in, OData had basically the same idea, however, from personal observation, somehow just didn't really become so popular, maybe because of its original association with Microsoft, etc. and also partially maybe its implementation. But it was pretty close, and today a lot of products support OData. I did note recently while reviewing the Microsoft API standard guidelines they share on GitHub [1], that there is a non-OData standard, but OData like recommendation for working with queries across collections, which I find to be pretty good and pretty generic. It seems like today you can do what you said - a sophisticated RESTish API without the model metadata piece pretty easily - but that metadata piece adds a lot of value. [1] https://github.com/Microsoft/api-guidelines/blob/vNext/Guidelines.md#9-collections https://github.com/Microsoft/api-guidelines/blob/vNext/Guide... - see sections on sorting, filtering etc.
  - dragonshed 8y ago
    This used to drive me crazy when GraphQL was first announced without a working download, compared to OData and several usable implementations. At the time there was also a compelling js library supporting OData.. [1]. > Breeze.js: Rich Data Management for the JavaScript Client > Client-side querying, caching, dynamic object graphs, change tracking and notification, model validation, batch save, offline support ... [1] https://github.com/breeze/breeze.js https://github.com/breeze/breeze.js Unfortunately I never had the opportunity to use it for a real project. [Edit formatting]
    - sixdimensional 8y ago
      Yeah, I have a project recently where GraphQL is actually a good fit conceptually, but I need a complete .NET client/server implementation and the open source ones are just about there, but I was still not confident enough to use it yet. Ugh. That Breeze framework was actually always super impressive. I guess there's a company behind it too. I've implemented some stuff with Telerik Kendo UI and OData (data grids, pivot tables) and it also is still working really quite well.
fefb 8y ago
I believe that article is referring when you need to fetch the data in differents places. Of course in your design, a single SQL query to you database would resolve it, probably you would use the same query for a Graphql resolve. But when a field need to be fetched from another database or document in a nosql, for example, graphql tends to be more organized, of course in a restful APi you would run some concurrents jobs and have the same result. I believe that best benefits that I got from graphql is flexibility in the endpoint with some basic validation data type and a good structure in the backend. However, about performance is debatable.
- iEchoic 8y ago
  > probably you would use the same query for a Graphql resolve When you're hand-writing SQL for a specific client experience, you can make optimizations that GraphQL cannot make because you have knowledge about the constraints on the information in the given context that GraphQL doesn't have. This is a tradeoff that comes with querying information in a generic way vs. querying information in a way that is specifically tailored for the experience. As a result, you often end up with queries that are faster than can be assembled by GraphQL.
  - fefb 8y ago
    What I meant is that you probably would use the same SQL script to fetch from your database the data. GraphQL is not responsible for talk to your database. If you have a SQL database, you must specify the SQL script to fetch the data as well as RESTFUL. Pay attention that GraphQL is not a database technology, Graphql is a query language for APIS.
    - iEchoic 8y ago
      Yeah, understood. I’m saying that you often don’t use the same SQL script you would if you were using GraphQL, because when you’re writing a SQL script for a very specific user experience you can often make optimizations that only work given the constraints of that experience and the data it needs.
acjohnson55 8y ago
I suspect they mean that you'll only have one client-server roundtrip for query and response.
- iEchoic 8y ago
  What if I’m requesting a user’s profile information and a list of posts on their profile, and the list of posts takes 10x longer to fetch? Is it faster from a client perspective if I can’t render the user’s profile page until I wait until all of the posts are fetched, too? In the general case, I’ve found that GraphQL is slower even in the case where you’re fetching all of a page’s info at once. Not only is it not necessarily always true that one client-server round trip is faster all-up than more granular requests even when you discount the user experience, this pattern often isn’t good general-case behavior for the reason above.

tango12 8y ago

This. Exactly this! I think anyone with experience will realise that you can get pretty much all the benefits of GraphQL with just a more sophisticated RESTish API. There is however, one thing that I think GraphQL backends have that REST backends don't, and that's the idea of introspection. Every GraphQL backend must be able to serve it's API data models and types. And I think the community tooling that leverages this makes it an amazing experience for app developers. No SDKs, any GraphQL client works with any GraphQL backend. Codegen esp for Android type apps to skip boilerplate of mapping APIs to POJOs. IDE autocomplete. I really think that the killer feature of GraphQL is that. We built a JSON DSL over a normal POST endpoint. Most GraphQL advantages sound "not really true" to me because you can always achieve the same thing (almost) yourself anyway.

iEchoic 8y ago
Yup, agreed - the developer experience and the self-documenting nature of GraphQL is a big plus. I no longer use GraphQL, but this is something I miss about it. As you mention though, people often don't realize that GraphQL is just a way to tell an endpoint that you want information in a generic way, and a pattern for having that endpoint resolve information in a generic way. It's an abstraction on top of a normal service call, and like most abstractions, it gives you consistency and ease-of-use but not any new capabilities you didn't have before.
sixdimensional 8y ago
Just wanted to chime in, OData had basically the same idea, however, from personal observation, somehow just didn't really become so popular, maybe because of its original association with Microsoft, etc. and also partially maybe its implementation. But it was pretty close, and today a lot of products support OData. I did note recently while reviewing the Microsoft API standard guidelines they share on GitHub [1], that there is a non-OData standard, but OData like recommendation for working with queries across collections, which I find to be pretty good and pretty generic. It seems like today you can do what you said - a sophisticated RESTish API without the model metadata piece pretty easily - but that metadata piece adds a lot of value. [1] https://github.com/Microsoft/api-guidelines/blob/vNext/Guidelines.md#9-collections https://github.com/Microsoft/api-guidelines/blob/vNext/Guide... - see sections on sorting, filtering etc.
- dragonshed 8y ago
  This used to drive me crazy when GraphQL was first announced without a working download, compared to OData and several usable implementations. At the time there was also a compelling js library supporting OData.. [1]. > Breeze.js: Rich Data Management for the JavaScript Client > Client-side querying, caching, dynamic object graphs, change tracking and notification, model validation, batch save, offline support ... [1] https://github.com/breeze/breeze.js https://github.com/breeze/breeze.js Unfortunately I never had the opportunity to use it for a real project. [Edit formatting]
  - sixdimensional 8y ago
    Yeah, I have a project recently where GraphQL is actually a good fit conceptually, but I need a complete .NET client/server implementation and the open source ones are just about there, but I was still not confident enough to use it yet. Ugh. That Breeze framework was actually always super impressive. I guess there's a company behind it too. I've implemented some stuff with Telerik Kendo UI and OData (data grids, pivot tables) and it also is still working really quite well.

fefb 8y ago

I believe that article is referring when you need to fetch the data in differents places. Of course in your design, a single SQL query to you database would resolve it, probably you would use the same query for a Graphql resolve. But when a field need to be fetched from another database or document in a nosql, for example, graphql tends to be more organized, of course in a restful APi you would run some concurrents jobs and have the same result. I believe that best benefits that I got from graphql is flexibility in the endpoint with some basic validation data type and a good structure in the backend. However, about performance is debatable.

iEchoic 8y ago
> probably you would use the same query for a Graphql resolve When you're hand-writing SQL for a specific client experience, you can make optimizations that GraphQL cannot make because you have knowledge about the constraints on the information in the given context that GraphQL doesn't have. This is a tradeoff that comes with querying information in a generic way vs. querying information in a way that is specifically tailored for the experience. As a result, you often end up with queries that are faster than can be assembled by GraphQL.
- fefb 8y ago
  What I meant is that you probably would use the same SQL script to fetch from your database the data. GraphQL is not responsible for talk to your database. If you have a SQL database, you must specify the SQL script to fetch the data as well as RESTFUL. Pay attention that GraphQL is not a database technology, Graphql is a query language for APIS.
  - iEchoic 8y ago
    Yeah, understood. I’m saying that you often don’t use the same SQL script you would if you were using GraphQL, because when you’re writing a SQL script for a very specific user experience you can often make optimizations that only work given the constraints of that experience and the data it needs.

acjohnson55 8y ago

I suspect they mean that you'll only have one client-server roundtrip for query and response.

iEchoic 8y ago
What if I’m requesting a user’s profile information and a list of posts on their profile, and the list of posts takes 10x longer to fetch? Is it faster from a client perspective if I can’t render the user’s profile page until I wait until all of the posts are fetched, too? In the general case, I’ve found that GraphQL is slower even in the case where you’re fetching all of a page’s info at once. Not only is it not necessarily always true that one client-server round trip is faster all-up than more granular requests even when you discount the user experience, this pattern often isn’t good general-case behavior for the reason above.