3 ms·

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 m

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.

gpmcadam 6y ago
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_okcupid_from_rest_to_graphql/gc6cx1z/?context=1 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_.
- btgeekboy 6y ago
  If the custom server they were referring to was OKWS (https://github.com/OkCupid/okws https://github.com/OkCupid/okws), I wouldn’t be surprised if it was basically a rewrite.
Jestar342 6y ago
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.
nicoburns 6y ago
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.
karmakaze 6y ago
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.
sradman 6y ago
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.
- aitchnyu 6y ago
  Did any team get bitten by security and performance issues of client-designed queries and cause the backend guys to whitelist specific graphql queries?
- appleflaxen 6y ago
  that's a really helpful description/explanation. thank you.
heroprotagonist 6y ago
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.

gpmcadam 6y ago

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_okcupid_from_rest_to_graphql/gc6cx1z/?context=1 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_.

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

Jestar342 6y ago

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.

nicoburns 6y ago

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.

karmakaze 6y ago

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.

sradman 6y ago

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.

aitchnyu 6y ago
Did any team get bitten by security and performance issues of client-designed queries and cause the backend guys to whitelist specific graphql queries?
appleflaxen 6y ago
that's a really helpful description/explanation. thank you.

heroprotagonist 6y ago

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.