3 ms·

You can execute GraphQL queries via GET and set a cache up for it like REST. Technically it's also allowed to cache POST requests but I guess anyone who comes a

You can execute GraphQL queries via GET and set a cache up for it like REST. Technically it's also allowed to cache POST requests but I guess anyone who comes across that is going to raise their eyebrows.

arinlen 4y ago
> You can execute GraphQL queries via GET and set a cache up for it like REST. Does it, though? It seems it really doesn't, nor was GraphQL designed with HTTP caching in mind. The only references to caching in GraphQL are vague hand-waiving arguments about how theoretically GraphQL implementations might be implemented with some sort of support for caching primary keys. But any type of HTTP caching is automatically excluded from GrahQL. To put it differently, is there any third-party caching solution for GraphQL? As far as I could gather, the answer is no.
- RedShift1 4y ago
  It looks like you are fixated on caching in GraphQL, but that's unnecessary, you can just cache GraphQL like REST, because in the end they are just GET requests. Just cache the GET request.
  - arinlen 4y ago
    > It looks like you are fixated on caching in GraphQL, but that's unnecessary Oh so one of the most basic feature of any API, one which has a direct impact on scalability and motivates entire product lines and businesses like CDNs, is now "unnecessary"? > you can just cache GraphQL like REST, Go ahead and show one example, please.
    - RedShift1 4y ago
      It's just a GET request. Same as REST. I don't know what you want me to show as an example. You can use Apache, nginx, squid, any proxying webserver worth its salt...
      - arinlen 4y ago
        > It's just a GET request. Same as REST. I'm not sure you understand the problem at all. Are you actually able to show an example or not? Because changing the HTTP verb doesn't magically change the problem, and passing query parameters as a request document renders these queries uncacheable. > You can use Apache, nginx, squid, any proxying webserver worth its salt... Great, pick the one you're familiar with, and just show the code. Well, unless you're not "worth its salt" or are completely oblivious to the problem domain.
        RedShift1 4y ago
        Check back in a couple of hours, I'm on my mobile right now
        Xenoamorphous 4y ago
        A GET request is a GET request and anything that can cache one doesn’t know or care whether it’s for REST, GraphQL, a binary file or anything else.
        RedShift1 4y ago
        Here's the code: https://github.com/RedShift1/graphql-cached-get https://github.com/RedShift1/graphql-cached-get Note that I made a very primitive implementation. Depending on which GraphQL node is queried, the request will be cached by the proxy or not. Apollo GraphQL server has much more fine grained methods of allowing caching (see https://www.apollographql.com/docs/apollo-server/performance/caching/ https://www.apollographql.com/docs/apollo-server/performance...) however I left the example code crude so you see exactly what's going on under the hood.
    - spion 4y ago
      see https://www.apollographql.com/docs/apollo-server/performance/apq/ https://www.apollographql.com/docs/apollo-server/performance...
      - arinlen 4y ago
        > see https://www.apollographql.com/docs/apollo-server/performance https://www.apollographql.com/docs/apollo-server/performance... Sorry, that doesn't cut it at all. Far from it. Being able to cache a response is not the same thing as optimizing queries that hit your database. Being able to cache a response means not having to hit your database to begin with, and save up on things like traffic going into your database, and round trip time. With REST APIs I can get a web service to return responses that are HTTP cacheable, put a nginx instance between the ingress controller and the web service, and serve responses to REST clients without even touching the web service that provides the REST API. I can even deploy nginx instances in separate regions. What's GraphQL's response to this basic usecase?
        spion 4y ago
        Did you take the time to read the article? I'll try a more specific link to a section https://www.apollographql.com/docs/apollo-server/performance/apq/#using-get-requests-with-apq-on-a-cdn https://www.apollographql.com/docs/apollo-server/performance...
    - jensneuse 4y ago
      Here's how we do it: https://wundergraph.com/docs/overview/features/caching https://wundergraph.com/docs/overview/features/caching We "persist" all operations using their name (unique) as part of the path. Variables are passed via query parameters. We also add a unique hash as query param which is generated by the configuration. This way, each "iteration" of the application invalidates the cache automatically. Additionally, we generate ETags for each request to reduce response payloads to zero when nothing changed. (https://wundergraph.com/docs/overview/features/automatic_content_revalidation_with_etags https://wundergraph.com/docs/overview/features/automatic_con...) Combined with the generated type-safe client, this is a very solid setup.
- pycal 4y ago
  i share your sentiment; in neo4j, a popular graph store, you can’t even get primary keys without a third-party plug-in (apoc)

arinlen 4y ago

> You can execute GraphQL queries via GET and set a cache up for it like REST. Does it, though? It seems it really doesn't, nor was GraphQL designed with HTTP caching in mind. The only references to caching in GraphQL are vague hand-waiving arguments about how theoretically GraphQL implementations might be implemented with some sort of support for caching primary keys. But any type of HTTP caching is automatically excluded from GrahQL. To put it differently, is there any third-party caching solution for GraphQL? As far as I could gather, the answer is no.

RedShift1 4y ago
It looks like you are fixated on caching in GraphQL, but that's unnecessary, you can just cache GraphQL like REST, because in the end they are just GET requests. Just cache the GET request.
- arinlen 4y ago
  > It looks like you are fixated on caching in GraphQL, but that's unnecessary Oh so one of the most basic feature of any API, one which has a direct impact on scalability and motivates entire product lines and businesses like CDNs, is now "unnecessary"? > you can just cache GraphQL like REST, Go ahead and show one example, please.
  - RedShift1 4y ago
    It's just a GET request. Same as REST. I don't know what you want me to show as an example. You can use Apache, nginx, squid, any proxying webserver worth its salt...
    - arinlen 4y ago
      > It's just a GET request. Same as REST. I'm not sure you understand the problem at all. Are you actually able to show an example or not? Because changing the HTTP verb doesn't magically change the problem, and passing query parameters as a request document renders these queries uncacheable. > You can use Apache, nginx, squid, any proxying webserver worth its salt... Great, pick the one you're familiar with, and just show the code. Well, unless you're not "worth its salt" or are completely oblivious to the problem domain.
      - RedShift1 4y ago
        Check back in a couple of hours, I'm on my mobile right now
      - Xenoamorphous 4y ago
        A GET request is a GET request and anything that can cache one doesn’t know or care whether it’s for REST, GraphQL, a binary file or anything else.
      - RedShift1 4y ago
        Here's the code: https://github.com/RedShift1/graphql-cached-get https://github.com/RedShift1/graphql-cached-get Note that I made a very primitive implementation. Depending on which GraphQL node is queried, the request will be cached by the proxy or not. Apollo GraphQL server has much more fine grained methods of allowing caching (see https://www.apollographql.com/docs/apollo-server/performance/caching/ https://www.apollographql.com/docs/apollo-server/performance...) however I left the example code crude so you see exactly what's going on under the hood.
  - spion 4y ago
    see https://www.apollographql.com/docs/apollo-server/performance/apq/ https://www.apollographql.com/docs/apollo-server/performance...
    - arinlen 4y ago
      > see https://www.apollographql.com/docs/apollo-server/performance https://www.apollographql.com/docs/apollo-server/performance... Sorry, that doesn't cut it at all. Far from it. Being able to cache a response is not the same thing as optimizing queries that hit your database. Being able to cache a response means not having to hit your database to begin with, and save up on things like traffic going into your database, and round trip time. With REST APIs I can get a web service to return responses that are HTTP cacheable, put a nginx instance between the ingress controller and the web service, and serve responses to REST clients without even touching the web service that provides the REST API. I can even deploy nginx instances in separate regions. What's GraphQL's response to this basic usecase?
      - spion 4y ago
        Did you take the time to read the article? I'll try a more specific link to a section https://www.apollographql.com/docs/apollo-server/performance/apq/#using-get-requests-with-apq-on-a-cdn https://www.apollographql.com/docs/apollo-server/performance...
  - jensneuse 4y ago
    Here's how we do it: https://wundergraph.com/docs/overview/features/caching https://wundergraph.com/docs/overview/features/caching We "persist" all operations using their name (unique) as part of the path. Variables are passed via query parameters. We also add a unique hash as query param which is generated by the configuration. This way, each "iteration" of the application invalidates the cache automatically. Additionally, we generate ETags for each request to reduce response payloads to zero when nothing changed. (https://wundergraph.com/docs/overview/features/automatic_content_revalidation_with_etags https://wundergraph.com/docs/overview/features/automatic_con...) Combined with the generated type-safe client, this is a very solid setup.
pycal 4y ago
i share your sentiment; in neo4j, a popular graph store, you can’t even get primary keys without a third-party plug-in (apoc)