4 ms·

> performance was always a lower consideration when it came to utilizing graphql That's strange, because I thought the main selling point was to consume only t

by toomim 7y ago

> performance was always a lower consideration when it came to utilizing graphql That's strange, because I thought the main selling point was to consume only the data you need. The client specifies exactly which fields it wants. Then it doesn't over-fetch. To make things higher performance.

wolfgang42 7y ago
GraphQL the protocol/language was designed for performance, but (when I tried GraphQL, which was several years ago) the server-side implementations seem to have had much less of a focus on it. It's true that the client doesn't over-fetch (and also doesn't need multiple round-trips), but at least when I tried the gql-js library it required the server to over-fetch: it would ask for individual records, and then do the field plucking/record joining itself; there was no way to intercept the query along the way to find out which fields it needed so you could only fetch those. I get the impression that the server libraries were designed to work with a document store or "fat" REST API that is only capable of taking a single ID and returning the entire record. In this situation it makes sense to have a separate middleware server to keep the big fetches and round-trips inside the datacenter and only give the client exactly what it needs, and needing a little more server power isn't a big deal. But, if you need to do something more sophisticated (even something as simple as only fetching certain fields from the datastore), they were no help whatsoever; when I was looking into it there wasn't even a way to parse the query into an AST and do the rest of the query planning yourself.
- gavinray 7y ago
  Echoing this, GraphQL is just a specification, and it is up to library authors how that spec is implemented. I think there might be a disconnect or misunderstanding in the developer about this. GraphQL is sort of like the Flux pattern for MVVM architecture. It isn't so much a thing as an idea.
jbjorge 7y ago
The client doesn't over-fetch, but the server might need to over-fetch from the db with generic sub-optimal queries to resolve all the fields. Your mileage may vary, but on the project at work where we tried to utilize GQL, it became apparant that it sometimes is incredibly complex to map between a GQL query and an efficient db-query. We're slowly migrating to REST for preformance's sake. The front-end devs might complain since they can't just write a query to get exactly what they want, but I'm quite sure our customers won't complain about 50KB being served in 30ms instead of 10KB being served in 400ms.
cunac 7y ago
from my experience, you might not need all the data in the first fetch but it is highly likely that it will be needed for subsequent renderings. What worked better for me is to make sure the client doesn't ask for the same data (ID) multiple times, client-side caching works wonders in that case

by toomim 7y ago

wolfgang42 7y ago

GraphQL the protocol/language was designed for performance, but (when I tried GraphQL, which was several years ago) the server-side implementations seem to have had much less of a focus on it. It's true that the client doesn't over-fetch (and also doesn't need multiple round-trips), but at least when I tried the gql-js library it required the server to over-fetch: it would ask for individual records, and then do the field plucking/record joining itself; there was no way to intercept the query along the way to find out which fields it needed so you could only fetch those. I get the impression that the server libraries were designed to work with a document store or "fat" REST API that is only capable of taking a single ID and returning the entire record. In this situation it makes sense to have a separate middleware server to keep the big fetches and round-trips inside the datacenter and only give the client exactly what it needs, and needing a little more server power isn't a big deal. But, if you need to do something more sophisticated (even something as simple as only fetching certain fields from the datastore), they were no help whatsoever; when I was looking into it there wasn't even a way to parse the query into an AST and do the rest of the query planning yourself.

gavinray 7y ago
Echoing this, GraphQL is just a specification, and it is up to library authors how that spec is implemented. I think there might be a disconnect or misunderstanding in the developer about this. GraphQL is sort of like the Flux pattern for MVVM architecture. It isn't so much a thing as an idea.

jbjorge 7y ago

The client doesn't over-fetch, but the server might need to over-fetch from the db with generic sub-optimal queries to resolve all the fields. Your mileage may vary, but on the project at work where we tried to utilize GQL, it became apparant that it sometimes is incredibly complex to map between a GQL query and an efficient db-query. We're slowly migrating to REST for preformance's sake. The front-end devs might complain since they can't just write a query to get exactly what they want, but I'm quite sure our customers won't complain about 50KB being served in 30ms instead of 10KB being served in 400ms.

cunac 7y ago

from my experience, you might not need all the data in the first fetch but it is highly likely that it will be needed for subsequent renderings. What worked better for me is to make sure the client doesn't ask for the same data (ID) multiple times, client-side caching works wonders in that case