3 ms·

It's less about the approach being popular and more about dealing with the hand you've been dealt. The use case for something like apollo-link-rest is "I'm in c

by exogen 8y ago

It's less about the approach being popular and more about dealing with the hand you've been dealt. The use case for something like apollo-link-rest is "I'm in control of the frontend only, and am being provided with a REST API." The popularity of it just speaks to how common it is for folks to find themselves in that scenario. Approaches like rest-graphql on the other hand involve being able to control the API piece, thus being able to offer the frontend a real GraphQL endpoint to talk to. Adapting REST APIs to GraphQL like this is definitely much more common than the client-side use case (which is more of a last resort), so don't let the stars fool you. It's just that (in my experience) people tend to roll REST-to-GraphQL resolvers by hand rather than use a helper like rest-graphql, because it tends to not be too difficult. Writing GraphQL resolvers is one of the aspects of it I find most enjoyable, actually.

froglegs 8y ago
what’s the point of resolving rest to graphql on the client if you’re not working with actual gql resources? what do you gain?
- exogen 8y ago
  In this case, you gain the Apollo helpers around entity management, caching, etc. and the components they've already created for sending queries & mutations – so the ecosystem basically. Also if you're planning in the future to migrate the API to GraphQL, and this is just a first step, you'll be able to leave most of the frontend code you wrote the same and just switch out the "link" part. It's kinda like how most languages have generic database adapters where you don't need to think about whether you're talking to MySQL/Postgres/SQLite etc. most of the time.
np_tedious 8y ago
Now that I re-read the library I linked above, I think I got it backwards there. rest-graphql is for the other direction: graphql to rest. I had previously investigated it in order to switch rest backend to graphql and provide a thin conversion layer so that several different clients could convert at their leisure. These two things are not at all comparable

by exogen 8y ago

froglegs 8y ago

what’s the point of resolving rest to graphql on the client if you’re not working with actual gql resources? what do you gain?

exogen 8y ago
In this case, you gain the Apollo helpers around entity management, caching, etc. and the components they've already created for sending queries & mutations – so the ecosystem basically. Also if you're planning in the future to migrate the API to GraphQL, and this is just a first step, you'll be able to leave most of the frontend code you wrote the same and just switch out the "link" part. It's kinda like how most languages have generic database adapters where you don't need to think about whether you're talking to MySQL/Postgres/SQLite etc. most of the time.

np_tedious 8y ago

Now that I re-read the library I linked above, I think I got it backwards there. rest-graphql is for the other direction: graphql to rest. I had previously investigated it in order to switch rest backend to graphql and provide a thin conversion layer so that several different clients could convert at their leisure. These two things are not at all comparable