6 ms·

It's great that GraphQL's solved some of your issues, and you've encouraged me to look into it a bit more. One thing you should worry about, though - if at any

by T-R 11y ago

It's great that GraphQL's solved some of your issues, and you've encouraged me to look into it a bit more. One thing you should worry about, though - if at any point there's any user-specific data in an HTTP response that doesn't have the user's ID in the URL (or something pointed to by the 'vary' header), it kills the idempotence of the request, whether you're using what Rails gives you or GraphQL or XML-RPC or whatever, which is pretty much the whole point of REST. It's not just REST-nazism, this completely destroys the usefulness of any cache past that point if it doesn't understand the internals of your API (as you seem to note that you've realized at the end of the article). It might make sense to just not expose the GraphQL to the client, so you can think about the idempotence of your requests from the backend, and allow yourself to keep making use of caching proxies and client-side cache.

jacobwg 11y ago
I have "read Relay source" on my todo list, since that's something that Relay is intended to solve (using GraphQL schema introspection to understand the responses from the server and intelligently compose queries and cache the data). We may eventually be able to utilize Relay on the web, but I'm more interested in understanding how Relay works conceptually in the interest of porting the logic to native platforms (iOS / Android). But I agree, it makes caching more difficult, especially with caching proxies.
- deleted 11y ago
  [deleted]
- mwcampbell 11y ago
  Do you have some way of sharing non-UI code between native mobile clients, e.g. Xamarin, RoboVM, or something JavaScript-based? React Native would be particularly appropriate here since you're using GraphQL and looking at Relay. Rewriting non-UI client code in two or more languages is unacceptable in my view, because it either encourages dumb clients, which is the opposite of what you want if you're using GraphQL, or leads to subtle discrepancies between platforms.
- T-R 11y ago
  It may be worth looking into HTTP 2. While it may or may not be supported widely enough for production yet, it provides for things like "server push", which should allow you to minimize network round trips while keeping components separately cacheable (and therefore not requiring you to do gymnastics with your API to keep your cache granularity down), which should be helpful both with and without GraphQL. I would recommend, either way, though, thinking about organizing your objects around how quickly they spoil for their given cache key (usually the URL) across multiple clients, since that ultimately determines where you can hit cache and where you need to make a new request, regardless of what libraries you're using.
paulddraper 11y ago
That's correct, you destroy HTTP-level caching. (For one, your queries can be large so are POSTed anyway.) Relay is a caching layer that understands GraphQL semantics, but you no longer have transparent HTTP proxies, browser caching, etc. Though HTTP proxies are dead thanks to HTTPS, and with modern browser APIs, you can do your own limited caching. It's certainly a tradeoff for what you expect to give you best performance gains: fewer roundtrips, or more caching by third parties.
- T-R 11y ago
  > Though HTTP proxies are dead thanks to HTTPS Well, they're not as broadly useful as without HTTPS, but you can still always MITM yourself to get a free transparent caching layer between the client and your end server.

by T-R 11y ago

jacobwg 11y ago

I have "read Relay source" on my todo list, since that's something that Relay is intended to solve (using GraphQL schema introspection to understand the responses from the server and intelligently compose queries and cache the data). We may eventually be able to utilize Relay on the web, but I'm more interested in understanding how Relay works conceptually in the interest of porting the logic to native platforms (iOS / Android). But I agree, it makes caching more difficult, especially with caching proxies.

deleted 11y ago
[deleted]
mwcampbell 11y ago
Do you have some way of sharing non-UI code between native mobile clients, e.g. Xamarin, RoboVM, or something JavaScript-based? React Native would be particularly appropriate here since you're using GraphQL and looking at Relay. Rewriting non-UI client code in two or more languages is unacceptable in my view, because it either encourages dumb clients, which is the opposite of what you want if you're using GraphQL, or leads to subtle discrepancies between platforms.
T-R 11y ago
It may be worth looking into HTTP 2. While it may or may not be supported widely enough for production yet, it provides for things like "server push", which should allow you to minimize network round trips while keeping components separately cacheable (and therefore not requiring you to do gymnastics with your API to keep your cache granularity down), which should be helpful both with and without GraphQL. I would recommend, either way, though, thinking about organizing your objects around how quickly they spoil for their given cache key (usually the URL) across multiple clients, since that ultimately determines where you can hit cache and where you need to make a new request, regardless of what libraries you're using.

paulddraper 11y ago

That's correct, you destroy HTTP-level caching. (For one, your queries can be large so are POSTed anyway.) Relay is a caching layer that understands GraphQL semantics, but you no longer have transparent HTTP proxies, browser caching, etc. Though HTTP proxies are dead thanks to HTTPS, and with modern browser APIs, you can do your own limited caching. It's certainly a tradeoff for what you expect to give you best performance gains: fewer roundtrips, or more caching by third parties.

T-R 11y ago
> Though HTTP proxies are dead thanks to HTTPS Well, they're not as broadly useful as without HTTPS, but you can still always MITM yourself to get a free transparent caching layer between the client and your end server.