5 ms·

Pardon me for asking a perhaps naive question, but how is this not a solution to a self-inflicted problem? Using a normal restful HTTP api has none of these iss

by doteka 5y ago

Pardon me for asking a perhaps naive question, but how is this not a solution to a self-inflicted problem? Using a normal restful HTTP api has none of these issues. What is the big problem that GraphQL solves, and is it really serious enough to reinvent existing infrastructure for it?

coffeedoughnuts 5y ago
> Using a normal restful HTTP api has none of these issues I don't think a normal HTTP api provides anything to help with cache invalidation after a write operation, does it?
- timsuchanek 5y ago
  +1
- simplyinfinity 5y ago
  https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ET... Etags can be used to check and invalidate content.
  - timsuchanek 5y ago
    Yes, but as long as a cached version is still returned at the edge (while the real content might have changed), the ETag won't help. It can only save you from unnecessarily downloading content you already have - in case it didn't change.
    - simplyinfinity 5y ago
      And when the content is updated you return different etag and the content is refreshed. Your system should have either distributed cache or a way for the edge to detect cache invalidations or for you to manually invalidate the cache on the edge.
      - timsuchanek 5y ago
        Exactly, that is what we provide. Including Etag support btw.
- doteka 5y ago
  As other commenters have mentioned, in fact it has functionality specific for this purpose. That is part of the underlying reason for my question: it often feels like the people pushing for graphql adoption are not aware what http is capable of out of the box.
timsuchanek 5y ago
That is not a naive, but very good question. Traditionally, many people assume, that GraphQL itself is hard to cache, while REST isn't, because REST can leverage HTTP's power, while GraphQL with its POST requests can't. However, that is missing the point. What we need to talk about first is, how you want to invalidate your cache. Do you want to set a TTL of 60 seconds? That might work for certain apps - both in REST and GraphQL, but many apps can't afford stale content for such an amount of time. You'll need cache invalidation when content changes. That on its own is a hard problem, no matter if REST, GraphQL or any other protocol. And it is one of the main reasons we built GraphCDN: Making it easy to purge the cache, when relevant content changed. How? We give you a purging api (also GraphQL) and additionally GraphQL has the concepts of mutations. Once you run a mutation through GraphCDN, it'll detect the relevant entities involved and purge the cache accordingly. So - yes, in GraphQL caching on the surface might seem harder - but we're not just solving the "I can't cache POST requests" problem, but rather give you powerful cache purging - which is only possible due to the well-defined structure of a typed GraphQL Schema. Because of that, we're actually thinking of providing REST "connectors" one day - turning REST into GraphQL, so you can have one unified interface that is easy to cache and invalidate.
- pier25 5y ago
  > You'll need cache invalidation when content changes Or you can use Vercel's stale-while-revalidate which will update the cache periodically while (temporarily) serving stale responses.
  - timsuchanek 5y ago
    Yes, which we btw also offer. However, it's just one way to invalidate. The first request after the max age expired will still be stale, even if new content is refetched within the swr time frame - in certain applications not acceptable. Most of our customers even use both things together to reduce the likelyhood for stale content.
pm90 5y ago
Having worked on a few backend teams, graphql solves the problem of decoupling frontend from backend. In theory, a well designed rest API should solve this. In practice, frontend teams want all sorts of metadata, want to change the shape of the data they’re fetching etc. Graphql let’s them do this without waiting on the backend team to make changes to the API. The frontend teams may not want direct access to a backend teams database. But they do want the backend to be flexible, and graphql allows for that.
philplckthun 5y ago
There are solutions to simply turn GraphQL requests into (traditional) CDN-cacheable requests. Usually this would be done using (Automatic) Persisted Queries, where a query is not only requested as a GET request, if it's not a mutation, but it'd also do so using a hash rather than an entire query. This has a couple of limitations that you'd also expect from a CDN cache for REST requests. However, I believe the interesting part about GraphCDN is that it can do more to look at the exact queries and mutations that are run to invalidate queries more precisely. So, it's likely worth saying that it's not that CDN caching GraphQL is hard, but getting invalidation and a high cache hit rate (just as with REST APIs) is hard.
pier25 5y ago
This is my impression of the whole GraphQL thing as well. It solves some problems on the querying side (that not everyone has). OTOH implementing it server-side is a major pain unless you rely on third party stuff like Hasura or GraphCDN. Personally I'll keep using REST as the default for the foreseeable future, and only use GraphQL when the problems it solves are more painful than the problems it introduces.
- handrous 5y ago
  > It solves some problems on the querying side (that not everyone has). OTOH implementing it server-side is a major pain unless you rely on third party stuff like Hasura or GraphCDN. I'm not even sure "major pain" suffices to describe it. It's such a mine-field to implement that if it's tractable and non-insane to do so for one's project, then the surface area of one's API must have been so tiny that using GraphQL was entirely unwarranted in the first place. [EDIT] I take that back: it can be fairly easy if your dataset is 100% public, read-only, and you don't care whatsoever about performance or limiting abuse.

by doteka 5y ago

coffeedoughnuts 5y ago

> Using a normal restful HTTP api has none of these issues I don't think a normal HTTP api provides anything to help with cache invalidation after a write operation, does it?

timsuchanek 5y ago
+1
simplyinfinity 5y ago
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ET... Etags can be used to check and invalidate content.
- timsuchanek 5y ago
  Yes, but as long as a cached version is still returned at the edge (while the real content might have changed), the ETag won't help. It can only save you from unnecessarily downloading content you already have - in case it didn't change.
  - simplyinfinity 5y ago
    And when the content is updated you return different etag and the content is refreshed. Your system should have either distributed cache or a way for the edge to detect cache invalidations or for you to manually invalidate the cache on the edge.
    - timsuchanek 5y ago
      Exactly, that is what we provide. Including Etag support btw.
doteka 5y ago
As other commenters have mentioned, in fact it has functionality specific for this purpose. That is part of the underlying reason for my question: it often feels like the people pushing for graphql adoption are not aware what http is capable of out of the box.

timsuchanek 5y ago

That is not a naive, but very good question. Traditionally, many people assume, that GraphQL itself is hard to cache, while REST isn't, because REST can leverage HTTP's power, while GraphQL with its POST requests can't. However, that is missing the point. What we need to talk about first is, how you want to invalidate your cache. Do you want to set a TTL of 60 seconds? That might work for certain apps - both in REST and GraphQL, but many apps can't afford stale content for such an amount of time. You'll need cache invalidation when content changes. That on its own is a hard problem, no matter if REST, GraphQL or any other protocol. And it is one of the main reasons we built GraphCDN: Making it easy to purge the cache, when relevant content changed. How? We give you a purging api (also GraphQL) and additionally GraphQL has the concepts of mutations. Once you run a mutation through GraphCDN, it'll detect the relevant entities involved and purge the cache accordingly. So - yes, in GraphQL caching on the surface might seem harder - but we're not just solving the "I can't cache POST requests" problem, but rather give you powerful cache purging - which is only possible due to the well-defined structure of a typed GraphQL Schema. Because of that, we're actually thinking of providing REST "connectors" one day - turning REST into GraphQL, so you can have one unified interface that is easy to cache and invalidate.

pier25 5y ago
> You'll need cache invalidation when content changes Or you can use Vercel's stale-while-revalidate which will update the cache periodically while (temporarily) serving stale responses.
- timsuchanek 5y ago
  Yes, which we btw also offer. However, it's just one way to invalidate. The first request after the max age expired will still be stale, even if new content is refetched within the swr time frame - in certain applications not acceptable. Most of our customers even use both things together to reduce the likelyhood for stale content.

pm90 5y ago

Having worked on a few backend teams, graphql solves the problem of decoupling frontend from backend. In theory, a well designed rest API should solve this. In practice, frontend teams want all sorts of metadata, want to change the shape of the data they’re fetching etc. Graphql let’s them do this without waiting on the backend team to make changes to the API. The frontend teams may not want direct access to a backend teams database. But they do want the backend to be flexible, and graphql allows for that.

philplckthun 5y ago

There are solutions to simply turn GraphQL requests into (traditional) CDN-cacheable requests. Usually this would be done using (Automatic) Persisted Queries, where a query is not only requested as a GET request, if it's not a mutation, but it'd also do so using a hash rather than an entire query. This has a couple of limitations that you'd also expect from a CDN cache for REST requests. However, I believe the interesting part about GraphCDN is that it can do more to look at the exact queries and mutations that are run to invalidate queries more precisely. So, it's likely worth saying that it's not that CDN caching GraphQL is hard, but getting invalidation and a high cache hit rate (just as with REST APIs) is hard.

pier25 5y ago

This is my impression of the whole GraphQL thing as well. It solves some problems on the querying side (that not everyone has). OTOH implementing it server-side is a major pain unless you rely on third party stuff like Hasura or GraphCDN. Personally I'll keep using REST as the default for the foreseeable future, and only use GraphQL when the problems it solves are more painful than the problems it introduces.

handrous 5y ago
> It solves some problems on the querying side (that not everyone has). OTOH implementing it server-side is a major pain unless you rely on third party stuff like Hasura or GraphCDN. I'm not even sure "major pain" suffices to describe it. It's such a mine-field to implement that if it's tractable and non-insane to do so for one's project, then the surface area of one's API must have been so tiny that using GraphQL was entirely unwarranted in the first place. [EDIT] I take that back: it can be fairly easy if your dataset is 100% public, read-only, and you don't care whatsoever about performance or limiting abuse.