Hacker News Reader

Comment by appleflaxen | Hacker News Reader

what is the theoretical benefit of going from REST to GraphQL?

Reading the post I don't understand what motivated this change?

The first footnote says:

  a more expressive way for clients to interact with our 
  data, a more performant way to retrieve data with fewer 
  network requests, more flexibility for our clients to 
  create new features without API changes once the graph 
  was built out a bit, and a technology that is rapidly 
  being adopted as a community standard for APIs.

but I don't understand what you could possibly want to do with your data that REST would make challenging.

Can anyone give me an example? Especially from a fairly straightforward data structure like a dating site.

View on HN

In most cases, I reckon it would be for the hell of it.

But in the reddit comments for the OP, the author of this article sheds some light:

> "Hey, author here! I chose to skip that part just because when I was researching our new API, I read so many posts just like that about how great GraphQL is. So I thought it might be more interesting to hear about some of the mechanics of executing the swap and making sure things didn’t go wrong in a production app."

> "But I will say that our previous API, while it worked well for years and enabled huge amounts of growth in our client codebases, was written in a language that was made up at OkCupid that came with our custom web server, so that’s one good reason to switch!"

https://www.reddit.com/r/reactjs/comments/jthwdz/moving_okcu...

I'm interested to see how large companies do these types of migrations, but for me, the more interesting story would've been how on earth some custom language was invented and used for a REST API and what they did to migrate _that_.

If the custom server they were referring to was OKWS (https://github.com/OkCupid/okws), I wouldn’t be surprised if it was basically a rewrite.

Maleable/dynamic client contract (as in endpoint contract) specification. That's it.

Client A may want to retrieve the User type along with a collection of recent Searches and PageViewed results, all in one request to reduce chattiness.

Client B (or even Client A in a different workflow) might want to retrieve the User type alongside MatchedProfiles or whatever. Again in on request to reduce chattiness.

GraphQL allows for this kind of flexibility, whereas in REST you'll need to either get chatty with the APIs or build and maintain a large number of boilerplate endpoints.

Similar to SQL, GraphQL allows dynamic manipulation of a result set. Projection (filtering columns), selection (filtering rows), and sort order can all be specified on the client. Traditionally, REST interfaces have a fixed response representation for each endpoint.

For a dating site, a user can have a custom configuration specifying which profile attributes to include or exclude which helps optimize response size. A user can also generate advanced queries based on a faceted search interface.

Did any team get bitten by security and performance issues of client-designed queries and cause the backend guys to whitelist specific graphql queries?

that's a really helpful description/explanation.

thank you.

So consider that these are not hugely different, if we're both using JSON over HTTP (ignoring the verb vs noun characterization of mutations).

I have worked where we did extend the REST implementation with optional flags for which fields you wanted to return and which relations (and relations of relations) you wanted returned in the same response to eliminate extra round trips. There was even a backend for (mobile) frontend (BFF) that made the extra round-trips all on the backend with tailored responses. Continue going down this road and you've essentially built a non-standard GraphQL from scratch. Like it says it's good to have stable models before taking this step.

I can see two potential benefits to GraphQL:

- If you have separate backend and frontend teams, then it enable better decoupling as it essentially specifies a minimum capability and flexibility that any backend API must meet.

- If you can use a 3rd party tool like Hasura to generate the GraphQL API then you get APIs (including realtime subscriptions) mostly for free without having to do any implementation work

Overall I agree that neither of these are super-compelling over REST in most cases, and REST apis have their own advantages around being flexible and better able to respond to complex use cases.

One benefit is simplifying the offline-first story. There is a lot of tooling around this and cloud graphql services like AWS AppSync include it out of the box.

It's perhaps less useful for web apps than mobile apps. Even there, retrieving only deltas of modified data can add efficiency over repeating REST calls. Which is possible with REST as well, but more complex.

Reply on news.ycombinator.com