4 ms·
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 respons
by 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 agoDo 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 agoIt 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.