From REST to GraphQL
blog.jacobwgillespie.com
From REST to GraphQL
1–10 of 46 posts
Re: From REST to GraphQL
#2This sounds like incompetent back-end design in the initial REST API. I never thought GraphQL would be more performant than REST-API + optimized queries. I don't have any experience with the current set of GraphQL libraries, but I've assumed that GraphQL is a solution to a completely different set of issues but with a possible performance penalty.
Re: From REST to GraphQL
#3This sounds like incompetent back-end design in the initial REST API. I never thought GraphQL would be more performant than REST-API + optimized queries. I don't have any experience with the current set of GraphQL libraries, but I've assumed that GraphQL is a solution to a completely different set of issues but with a possible performance penalty.
> This sounds like incompetent back-end design in the initial REST API.
It doesn't even qualify as REST. They've got hard-coded URI hierarchies and IDs everywhere. That's the opposite of REST.
REST APIs must be hypertext-driven: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte...
Re: From REST to GraphQL
#4Terrific writeup - thanks for sharing. IMHO this is the most important item: "We have yet to solve caching GraphQL responses on the client."
Mobile client-side caching and sync/refreshing (or client-side change push) is where users get big gains in perceived speed gains. Fielding's REST handles this well, in my experience, though it takes some work to get the resource granularity correct, especially as a mobile app's feature needs are changing.
In my experience it's often the case that the mobile app can benefit from Fielding's REST (with HATEOS) and from using resources that are mobile-specific and quite different than the out-of-the box server-side models that map 1:1 to database rows. As an example, the JSON API team describes how to nest resources efficiently and cacheably, and also send HATEOS links.
I'll be very interested to hear more about your next steps, including how you decide to do caching, puts, and any kind of pub/sub or equivalent. Thanks again!
Re: From REST to GraphQL
#5This sounds like incompetent back-end design in the initial REST API. I never thought GraphQL would be more performant than REST-API + optimized queries. I don't have any experience with the current set of GraphQL libraries, but I've assumed that GraphQL is a solution to a completely different set of issues but with a possible performance penalty.
> This sounds like incompetent back-end design in the initial REST API. It doesn't even qualify as REST. They've got hard-coded URI hierarchies and IDs everywhere. That's the opposite of REST. REST APIs must be hypertext-driven: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte...
Yep, you are right - I think our previous implementation would be better described as a "typical HTTP Rails JSON API." As I briefly alluded in the article, we actually initially had a hypertext-driven API using RFC 6570 URI templates, but had to eventually change designs to increase performance for mobile apps. Payloads needed to be smaller and we couldn't afford the extra requests necessary to traverse the endpoints.
But yes, I agree, what is commonly called "REST" isn't usually.
Re: From REST to GraphQL
#6It'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.
Re: From REST to GraphQL
#7I've heard some rumblings about adding GraphQL as a feature to Elixir / Phoenix. Anyone know more about this?
Re: From REST to GraphQL
#8Terrific writeup - thanks for sharing. IMHO this is the most important item: "We have yet to solve caching GraphQL responses on the client." Mobile client-side caching and sync/refreshing (or client-side change push) is where users get big gains in perceived speed gains. Fielding's REST handles this well, in my experience, though it takes some work to get the resource granularity correct, especially as a mobile app's…
Glad you enjoyed it! As someone pointed out below, what we were doing before is not true REST, and we may have been able to solve our problem in other ways (HATEOS, "true REST", etc.) - we experimented with some HATEOS-esque URI templates early on, similar to how Github's API implements them, though personally I feel like I need to study more to understand true REST and HATEOS.
I will definitely follow up with our findings as we progress towards solving our remaining challenges.
Re: From REST to GraphQL
#9It'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 what…
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.
Re: From REST to GraphQL
#10Another possible solution while sticking to REST: instead of embedding all the sub-objects have an "expand" query param where you can list all the sub-objects/relationships you'd like returned (EG: GET /playlists/ID?expand=tags,tracks) This way you can still do everything in one request but not bloat the response data structure for situations that don't need the sub-objects.