5 ms·

> GraphQL is a great experience when you consume it and the service fulfills your query needs. Because you just ask stuff and you get them. It's really cool.

> GraphQL is a great experience when you consume it and the service fulfills your query needs. Because you just ask stuff and you get them. It's really cool. How about caching? It feels like GraphQL tries to win some (arguable) flexibility in putting together clients and in the process throws out most of the operational advantages of resource-based APIs with significant disadvantages in both how to put together a backend.

RedShift1 4y ago
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
  - 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)
lexx 4y ago
One solution is "Persistent Queries". Other solution is to throw a Varnish Cache and cache the hell out of POST requests :P Is it elegant? No. Do you have another service to manage? Yes Will you pay someone else to do it for you? Possibly I think there are already products trying to do that. But how many layers of abstractions and dependencies are you willing to have in your everyday processes?
tracyhenry 4y ago
Checkout Relay.js: https://relay.dev/ https://relay.dev/ It does a lot of client-side caching for you. The documentation is atrocious though IMO. I'm not sure if there exists a similar framework for backend caching.
- arinlen 4y ago
  > Checkout Relay.js: https://relay.dev/ https://relay.dev/ Relay is a GraphQL client. That's the irrelevant side of caching, because that can be trivially implemented by an intern, specially given GraphQL's official copout of caching based on primary keys [1], and doesn't have any meaningful impact on the client's resources. The relevant side of caching is server-side caching: the bits of your system that allow it to fulfill results while skipping the expensive bits, like having to hit the database. This is what really matters both in terms of operational costs and performance, and this is what GraphQL fails to deliver. [1] https://graphql.org/learn/caching/ https://graphql.org/learn/caching/
  - tracyhenry 4y ago
    https://relay.dev/docs/principles-and-architecture/thinking-in-graphql/ https://relay.dev/docs/principles-and-architecture/thinking-... Take a look at this. Either you didn't know what's challenging about caching nested graph data, or we have different definitions of triviality/interns.
    - arinlen 4y ago
      > Take a look at this. I repeat: client-side caching is not a problem, even with GraphQL. The technical problems regarding GraphQL's blockers to caching lies in server-side caching. For server-side caching, the only answer that GraphQL offers is to use primary keys, hand-wave a lot, and hope that your GraphQL implementation did some sort of optimization to handle that corner case by caching results. Don't take my word for it. It's really that bad. https://graphql.org/learn/caching/ https://graphql.org/learn/caching/

RedShift1 4y ago

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
- 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)

lexx 4y ago

One solution is "Persistent Queries". Other solution is to throw a Varnish Cache and cache the hell out of POST requests :P Is it elegant? No. Do you have another service to manage? Yes Will you pay someone else to do it for you? Possibly I think there are already products trying to do that. But how many layers of abstractions and dependencies are you willing to have in your everyday processes?

tracyhenry 4y ago

Checkout Relay.js: https://relay.dev/ https://relay.dev/ It does a lot of client-side caching for you. The documentation is atrocious though IMO. I'm not sure if there exists a similar framework for backend caching.

arinlen 4y ago
> Checkout Relay.js: https://relay.dev/ https://relay.dev/ Relay is a GraphQL client. That's the irrelevant side of caching, because that can be trivially implemented by an intern, specially given GraphQL's official copout of caching based on primary keys [1], and doesn't have any meaningful impact on the client's resources. The relevant side of caching is server-side caching: the bits of your system that allow it to fulfill results while skipping the expensive bits, like having to hit the database. This is what really matters both in terms of operational costs and performance, and this is what GraphQL fails to deliver. [1] https://graphql.org/learn/caching/ https://graphql.org/learn/caching/
- tracyhenry 4y ago
  https://relay.dev/docs/principles-and-architecture/thinking-in-graphql/ https://relay.dev/docs/principles-and-architecture/thinking-... Take a look at this. Either you didn't know what's challenging about caching nested graph data, or we have different definitions of triviality/interns.
  - arinlen 4y ago
    > Take a look at this. I repeat: client-side caching is not a problem, even with GraphQL. The technical problems regarding GraphQL's blockers to caching lies in server-side caching. For server-side caching, the only answer that GraphQL offers is to use primary keys, hand-wave a lot, and hope that your GraphQL implementation did some sort of optimization to handle that corner case by caching results. Don't take my word for it. It's really that bad. https://graphql.org/learn/caching/ https://graphql.org/learn/caching/