5 ms·

It's incredibly difficult to optimize performance around. With REST, I know how the data is being presented, and can craft DB queries with focused indexes to e

It's incredibly difficult to optimize performance around. With REST, I know how the data is being presented, and can craft DB queries with focused indexes to ensure it's as fast as possible.

dudul 6y ago
What prevents you from doing that with graphql? You're still getting parameters to use in your DB queries.
- calrain 6y ago
  Being able to predict how your customers use your API has a strong impact on how you deliver the data behind the API. If we're talking about highly interconnected objects in an API, it would be expensive (from a DB point of view) to arbitrarily add indexes in the long shot case that someone may use a selector on that property. Equally, when data is highly interconnected, by designing an API that focuses on particular consumption patterns, I'm able to add custom functionality, pre-processing, or highly customised queries/indexes to ensure the data is read as fast as possible. Poor performing API's are bad for the consumer, bad for the database, and bad for the art of data. There's a balance between centralization and independence in software models that is so hard to balance right. MicroServices, GraphQL, and Docker Swarms are examples of technologies that, if done right, can be enabling, and if done wrong, will pull the ship to the bottom of the ocean.
andrewingram 6y ago
It's not that hard. For sure it's not trivial, but the thing you just said about REST is equally true for GraphQL -- you can literally solve performance in the same way. Ultimately fulfilling the data requirements for a use case boils down to composing the results of a bunch of I/O calls, the only real difference between REST and GraphQL is how these calls are triggered and their results composed.
- initplus 6y ago
  Sure, but the design of GraphQL, and the majority of the GraphQL backend tooling, lends itself to performance issues much more strongly than a boring REST API. I don't know if there are alternative backend tools, but my experience has been quite painful. The "graph" part - GraphQL seems to want you to build these big interconnected webs of types. But there isn't good tooling on the backend to deal with resolving relationships between types efficiently. Someone decides they need user.friends.pets.names, and now my backend code is doing 3 DB round trips because my GraphQL server lib doesn't understand it can turn the relationship between the types into a JOIN. I decide that's no good and the query needs to be faster, the alternative is I have to do the JOIN every time even if the client didn't actually request friends. And if I'm going to overfetch from the DB, might as well send that data to the client anyway? My experience was that because of how backend GraphQL servers are written, it becomes very challenging to reason about performance. It's hard to think about how your nice type resolvers are going to interact, and fan out into some nightmare n+1 query problem performance pit. I know there are some better tools than this, which I sadly haven't tried...
  - andrewingram 6y ago
    But if you were fetching the same data with a REST API (one that doesn't allow inclusion of relation fields, such as the JSON-API spec), you'd be doing the same amount of I/O and have the same horrible n+1 problem just between the client and server rather than inside the server, so it's spread across numerous requests rather than just one. Tools like Dataloader solve the n+1 problem quite effectively, and they've been around for about 5 years, making it a solved problem for the overwhelming majority of GraphQL's open source existence. If you look at the examples I wrote in this article (https://andrewingram.net/posts/optimising-graphql-request-waterfalls/ https://andrewingram.net/posts/optimising-graphql-request-wa...), in the waterfall charts each "call" is roughly equivalent to one simple (and usually easy to optimise) database query. I don't want to unduly trivialise the work in getting Dataloader properly integrated, but I will say it doesn't take a lot to start seeing the fruits of your effort.
    - fogetti 6y ago
RedShift1 6y ago
If you create those indexes for REST API's you can just as well create those indexes for GraphQL API's?
- GordonS 6y ago
  It's not just about indexes though, it's also about hand-crafted database queries.
  - RedShift1 6y ago
    GraphQL doesn't exclude hand-crafted database queries. If that is what needed you can perfectly make that fit with GraphQL. And if for some reason it won't fit in GraphQL, you could still create a one-off REST endpoint.
    - kikimora 6y ago
      And also introduce all REST tooling in addition to GraphQL. At this time people often start thinking "why I didn't start with REST in the first place?"

It's incredibly difficult to optimize performance around. With REST, I know how the data is being presented, and can craft DB queries with focused indexes to ensure it's as fast as possible.

dudul 6y ago

What prevents you from doing that with graphql? You're still getting parameters to use in your DB queries.

calrain 6y ago
Being able to predict how your customers use your API has a strong impact on how you deliver the data behind the API. If we're talking about highly interconnected objects in an API, it would be expensive (from a DB point of view) to arbitrarily add indexes in the long shot case that someone may use a selector on that property. Equally, when data is highly interconnected, by designing an API that focuses on particular consumption patterns, I'm able to add custom functionality, pre-processing, or highly customised queries/indexes to ensure the data is read as fast as possible. Poor performing API's are bad for the consumer, bad for the database, and bad for the art of data. There's a balance between centralization and independence in software models that is so hard to balance right. MicroServices, GraphQL, and Docker Swarms are examples of technologies that, if done right, can be enabling, and if done wrong, will pull the ship to the bottom of the ocean.

andrewingram 6y ago

It's not that hard. For sure it's not trivial, but the thing you just said about REST is equally true for GraphQL -- you can literally solve performance in the same way. Ultimately fulfilling the data requirements for a use case boils down to composing the results of a bunch of I/O calls, the only real difference between REST and GraphQL is how these calls are triggered and their results composed.

initplus 6y ago
Sure, but the design of GraphQL, and the majority of the GraphQL backend tooling, lends itself to performance issues much more strongly than a boring REST API. I don't know if there are alternative backend tools, but my experience has been quite painful. The "graph" part - GraphQL seems to want you to build these big interconnected webs of types. But there isn't good tooling on the backend to deal with resolving relationships between types efficiently. Someone decides they need user.friends.pets.names, and now my backend code is doing 3 DB round trips because my GraphQL server lib doesn't understand it can turn the relationship between the types into a JOIN. I decide that's no good and the query needs to be faster, the alternative is I have to do the JOIN every time even if the client didn't actually request friends. And if I'm going to overfetch from the DB, might as well send that data to the client anyway? My experience was that because of how backend GraphQL servers are written, it becomes very challenging to reason about performance. It's hard to think about how your nice type resolvers are going to interact, and fan out into some nightmare n+1 query problem performance pit. I know there are some better tools than this, which I sadly haven't tried...
- andrewingram 6y ago
  But if you were fetching the same data with a REST API (one that doesn't allow inclusion of relation fields, such as the JSON-API spec), you'd be doing the same amount of I/O and have the same horrible n+1 problem just between the client and server rather than inside the server, so it's spread across numerous requests rather than just one. Tools like Dataloader solve the n+1 problem quite effectively, and they've been around for about 5 years, making it a solved problem for the overwhelming majority of GraphQL's open source existence. If you look at the examples I wrote in this article (https://andrewingram.net/posts/optimising-graphql-request-waterfalls/ https://andrewingram.net/posts/optimising-graphql-request-wa...), in the waterfall charts each "call" is roughly equivalent to one simple (and usually easy to optimise) database query. I don't want to unduly trivialise the work in getting Dataloader properly integrated, but I will say it doesn't take a lot to start seeing the fruits of your effort.
  - fogetti 6y ago

RedShift1 6y ago

If you create those indexes for REST API's you can just as well create those indexes for GraphQL API's?

GordonS 6y ago
It's not just about indexes though, it's also about hand-crafted database queries.
- RedShift1 6y ago
  GraphQL doesn't exclude hand-crafted database queries. If that is what needed you can perfectly make that fit with GraphQL. And if for some reason it won't fit in GraphQL, you could still create a one-off REST endpoint.
  - kikimora 6y ago
    And also introduce all REST tooling in addition to GraphQL. At this time people often start thinking "why I didn't start with REST in the first place?"