4 ms·

You can use GET. https://graphql.org/learn/serving-over-http/#get-request https://graphql.org/learn/serving-over-http/#get-request That being said, caching nee

You can use GET. https://graphql.org/learn/serving-over-http/#get-request https://graphql.org/learn/serving-over-http/#get-request That being said, caching needs to be done at the resolution layer rather than the request layer. Under REST, APIs are generally modeled as returning individual objects or lists of one kind of object, which makes requests a reasonable thing to cache. Under GraphQL, each resolver returns a different type of content, and the mixed bag of content means that there should probably be different cache policies and invalidation for each kind of data provided by each resolver. The status code being 200 even though your query is wrong or failed to correctly return data makes sense for the same reason. If you got a 500 because one field failed to correctly resolve, but the rest of the query was fine, the 500 is only telling you that something went wrong without letting you know exactly what it is. In GraphQL, we should save the status codes for request-level network issues rather than semantic issues with the request or the response.

throwaway413 4y ago
Sure you can query over GET but to a single endpoint - so no ability to utilize built in browser caching for any requests you want to optimize unless you offload them from graphql. As for the 500, you can pass error details in the payload just as GraphQL would return as well, so sure you can get specifics of what went wrong. There’s clearly value in GQL for specific use cases but IMO it’s often an early over-optimization that shouldn’t encapsulate your entire data layer until you actually need it for reasons and not just to stay bleeding edge.
- TurningCanadian 4y ago
  You can query multiple endpoints and have the server return the most restrictive cache time. https://www.apollographql.com/docs/apollo-server/performance/caching#calculating-cache-behavior https://www.apollographql.com/docs/apollo-server/performance...
- striking 4y ago
  My point was that request level caching basically doesn't make sense for GraphQL anyway. I feel like you haven't replied to that point. And if you're reading the error details from the payload anyway, why bother with setting the error code when it has another, request-level, meaning? Not sure how any of this proves GQL is a premature optimization when caching could just as well be considered a premature optimization.
  - throwaway413 4y ago
    To the former point, you’re saying it doesn’t make sense for GQL, I’m saying why fix what isn’t broken? Request level caching works great for certain needs. But I get your point that it doesn’t apply as directly for GQL and yes, people do have these needs also. To the latter - at least with fetch, reading the response payload is a second blocking call after running the initial request. You can read the status with one less method. Amazing argument for pre-optimization? No, I get it, but it just feels like more overhead in practice to me at least. I think the point has been made clear to me that there is definitely one or more use cases that GraphQL solves for better than REST, and it is still right to pick and choose the right tech for each specific job as it fits best.

throwaway413 4y ago

Sure you can query over GET but to a single endpoint - so no ability to utilize built in browser caching for any requests you want to optimize unless you offload them from graphql. As for the 500, you can pass error details in the payload just as GraphQL would return as well, so sure you can get specifics of what went wrong. There’s clearly value in GQL for specific use cases but IMO it’s often an early over-optimization that shouldn’t encapsulate your entire data layer until you actually need it for reasons and not just to stay bleeding edge.

TurningCanadian 4y ago
You can query multiple endpoints and have the server return the most restrictive cache time. https://www.apollographql.com/docs/apollo-server/performance/caching#calculating-cache-behavior https://www.apollographql.com/docs/apollo-server/performance...
striking 4y ago
My point was that request level caching basically doesn't make sense for GraphQL anyway. I feel like you haven't replied to that point. And if you're reading the error details from the payload anyway, why bother with setting the error code when it has another, request-level, meaning? Not sure how any of this proves GQL is a premature optimization when caching could just as well be considered a premature optimization.
- throwaway413 4y ago
  To the former point, you’re saying it doesn’t make sense for GQL, I’m saying why fix what isn’t broken? Request level caching works great for certain needs. But I get your point that it doesn’t apply as directly for GQL and yes, people do have these needs also. To the latter - at least with fetch, reading the response payload is a second blocking call after running the initial request. You can read the status with one less method. Amazing argument for pre-optimization? No, I get it, but it just feels like more overhead in practice to me at least. I think the point has been made clear to me that there is definitely one or more use cases that GraphQL solves for better than REST, and it is still right to pick and choose the right tech for each specific job as it fits best.