3 ms·

Here's what just sending a request looks like with React + Apollo: https://codesandbox.io/s/q71px7njrw https://codesandbox.io/s/q71px7njrw Which boilerplate do

by exogen 8y ago

Here's what just sending a request looks like with React + Apollo: https://codesandbox.io/s/q71px7njrw https://codesandbox.io/s/q71px7njrw Which boilerplate do you take issue with? There are a couple imports you might find ugly, I suppose. Most likely though the blog post we're talking about isn't a good impression of what "just making a request" looks like. :)

lhorie 8y ago
This assumes a GraphQL backend though. A lot of React shops still use a combination of redux and REST APIs, which are admittedly a tad on the verbose side
- exogen 8y ago
  Seeing as the article under discussion is all about GraphQL, maybe the top-level comment was off-topic? Another thing to consider though, and something I've done in the past, is that you can actually embed the GraphQL resolver runtime completely on the client and easily adapt REST endpoints to it. It's pretty neat! So you can use all the benefits of Apollo without actually having a server that speaks GraphQL. This Apollo project is one such way to do that: https://github.com/apollographql/apollo-link-rest https://github.com/apollographql/apollo-link-rest (although not the strategy I used... I don't think Apollo even existed yet at the time)
  - froglegs 8y ago
    It was slightly off topic but I can understand it seeing as the example is in React/jsx and ember gets no love :) Personally jsx makes the hair on my body stand upright but that’s just me!
    - exogen 8y ago
      Likewise, I feel the same way about template DSLs (why add yet another language's control flow/scoping/etc. into the mix?). I think if JSX had been around first, many more developers would find templates off-putting, seeing as they amount to writing code that builds up other code as a string. It's just that they're the way things were done for so long... I wonder what a newer dev's take would be? Would they find UI elements as values/expressions weird, or UI elements as strings weird?
      - froglegs 8y ago
        I can see that argument... the same could be said about learning jsx as a layer on top of native js.. Before spa’s it was just interpolated strings rendered on the server.. people probably thought the same thing when rendering a string of html inside their python/ruby/java program. My take is if it gets the done and the team agrees, use whatever tool works! In ember-land, single file components are in the pipeline I believe, will be interesting to see if they end up supporting jsx too.
      - mnutt 8y ago
        Ember’s HTMLBars is no more “building up code as a string” than jsx is.
  - np_tedious 8y ago
    I hadn't seen a client-side approach for that translation before, but I do know if a server-side one here: https://github.com/remind101/rest-graphql https://github.com/remind101/rest-graphql The amount of stars would suggest the client approach is more popular. It's that consistent with your experience or am I not comparing apples to apples?
    - 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.

by exogen 8y ago

lhorie 8y ago

This assumes a GraphQL backend though. A lot of React shops still use a combination of redux and REST APIs, which are admittedly a tad on the verbose side

exogen 8y ago
Seeing as the article under discussion is all about GraphQL, maybe the top-level comment was off-topic? Another thing to consider though, and something I've done in the past, is that you can actually embed the GraphQL resolver runtime completely on the client and easily adapt REST endpoints to it. It's pretty neat! So you can use all the benefits of Apollo without actually having a server that speaks GraphQL. This Apollo project is one such way to do that: https://github.com/apollographql/apollo-link-rest https://github.com/apollographql/apollo-link-rest (although not the strategy I used... I don't think Apollo even existed yet at the time)
- froglegs 8y ago
  It was slightly off topic but I can understand it seeing as the example is in React/jsx and ember gets no love :) Personally jsx makes the hair on my body stand upright but that’s just me!
  - exogen 8y ago
    Likewise, I feel the same way about template DSLs (why add yet another language's control flow/scoping/etc. into the mix?). I think if JSX had been around first, many more developers would find templates off-putting, seeing as they amount to writing code that builds up other code as a string. It's just that they're the way things were done for so long... I wonder what a newer dev's take would be? Would they find UI elements as values/expressions weird, or UI elements as strings weird?
    - froglegs 8y ago
      I can see that argument... the same could be said about learning jsx as a layer on top of native js.. Before spa’s it was just interpolated strings rendered on the server.. people probably thought the same thing when rendering a string of html inside their python/ruby/java program. My take is if it gets the done and the team agrees, use whatever tool works! In ember-land, single file components are in the pipeline I believe, will be interesting to see if they end up supporting jsx too.
    - mnutt 8y ago
      Ember’s HTMLBars is no more “building up code as a string” than jsx is.
- np_tedious 8y ago
  I hadn't seen a client-side approach for that translation before, but I do know if a server-side one here: https://github.com/remind101/rest-graphql https://github.com/remind101/rest-graphql The amount of stars would suggest the client approach is more popular. It's that consistent with your experience or am I not comparing apples to apples?
  - 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.