From REST to GraphQL • Hacker News Board

Re: From REST to GraphQL

#11

Post by HaloZero » Sat, Oct 10, 2015, 5:35 PM UTC

jacobwg wrote: post #5

JimDabell wrote: post #3

Earlier quoted context omitted.

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

So by increasing the payload you've improved the performance of the mobile app by reducing the # of requests that you had to do?

Re: From REST to GraphQL

#12

Post by [deleted] » Sat, Oct 10, 2015, 5:43 PM UTC

jacobwg wrote: post #9

T-R wrote: post #6

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

[deleted]

Re: From REST to GraphQL

#13

Post by tyre » Sat, Oct 10, 2015, 5:52 PM UTC

> Future Puzzles

> Looking forward, here are a few things we are currently looking to solve:

> Mutations (Writes)

I agree that this is a more compelling way to structure GET requests, but REST and GraphQL are not comparable until they are solving the same problem.

Writes are a huge piece of RESTful interfaces (PUT, POST, PATCH, DELETE). I'm happy Facebook is open sourcing their work, but it does a disservice to GraphQL to compare it with REST.

Perhaps the title would have been better as "From REST reads to GraphQL."

Re: From REST to GraphQL

#14

Post by mwcampbell » Sat, Oct 10, 2015, 5:55 PM UTC

jacobwg wrote: post #9

T-R wrote: post #6

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

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.

Re: From REST to GraphQL

#15

Post by tunesmith » Sat, Oct 10, 2015, 5:58 PM UTC

It seems like a really common use case where

1) The service wants to keep its API general, and not client-aware

conflicts with

2) The client wants to assert a client-specific spec on the returned data

(e.g. the track tags, etc)

One of the other possible options would have been to keep the general API and then have a separate client-aware bespoke service that consumes it, and serves as the intermediary. Back in the SOA days they called this "service composition". There are real tradeoffs there though, in that you also want to avoid fully synchronous (nested) service-calling-service scenarios because then latency and SLA becomes the choking point. Caching doesn't fully solve that. More reactive architectures start to help out at that point, where consumers are not necessarily waiting for the full response before they take action.

Re: From REST to GraphQL

#16

Post by buro9 » Sat, Oct 10, 2015, 6:01 PM UTC

I quite like GraphQL, but only as a filter and composition layer in addition to a REST interface.

REST gives elegance to the non-GET operations and it is only the caching, JSON size, and composition of multiple resources that can sometimes be a strain for some applications (or all applications if the REST API is designed badly).

I'm probably going to investigate providing a common GraphQL query interface to my REST API. This would internally be an orchestration layer providing the filtering of properties as well as the composition of resources, and of course the instructions to that layer would be GraphQL queries. This would allow internally cacheable resources (perhaps via ESIs) and the filter would be applied in front of the cache layer.

I'm not yet at the point where I think GraphQL replaces REST, instead it complements it.

Re: From REST to GraphQL

#17

Post by T-R » Sat, Oct 10, 2015, 6:02 PM UTC

jacobwg wrote: post #9

T-R wrote: post #6

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

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.

Re: From REST to GraphQL

#18

Post by mercurial » Sat, Oct 10, 2015, 6:08 PM UTC

Hmm. From what I understand of GraphQL, it gives you:

- less boilerplate (no need to create GET REST endpoints and corresponding JS AJAX calls)

- consequently, more flexibility (just request more data in the client, no need to update server code)

- formalized query language (and apparently, the ability to check it?)

However, the idea of exposing your schema to arbitrary requests sounds much too dangerous to me. I see the advantages for really large applications, but I'll stick to REST with a 'format' parameter for the foreseeable future.

Re: From REST to GraphQL

#19

Post by RussianCow » Sat, Oct 10, 2015, 6:11 PM UTC

mercurial wrote: post #18

Hmm. From what I understand of GraphQL, it gives you: - less boilerplate (no need to create GET REST endpoints and corresponding JS AJAX calls) - consequently, more flexibility (just request more data in the client, no need to update server code) - formalized query language (and apparently, the ability to check it?) However, the idea of exposing your schema to arbitrary requests sounds much too dangerous to me. I see…

This seems to be a common misconception. GraphQL is just a protocol; query fields don't have to be tied to your schema at all, so you don't have to expose anything you don't want to, in the same way that you don't have to make every table accessible via REST.

Re: From REST to GraphQL

#20

Post by mercurial » Sat, Oct 10, 2015, 6:22 PM UTC

RussianCow wrote: post #19

mercurial wrote: post #18

Hmm. From what I understand of GraphQL, it gives you: - less boilerplate (no need to create GET REST endpoints and corresponding JS AJAX calls) - consequently, more flexibility (just request more data in the client, no need to update server code) - formalized query language (and apparently, the ability to check it?) However, the idea of exposing your schema to arbitrary requests sounds much too dangerous to me. I see…

This seems to be a common misconception. GraphQL is just a protocol; query fields don't have to be tied to your schema at all, so you don't have to expose anything you don't want to, in the same way that you don't have to make every table accessible via REST.

Let me rephrase that: you are exposing a way to trivially traverse the entire object graph you're exposing through the API, putting you at risk of DOSing your server when your friend Joe the frontend dev makes a small mistake in his query. You can obviously get the same result with REST, but usually you have to work a lot harder for it.