Hacker News Reader

Hacker News

Comment by EduardoBautista | Hacker News Reader

Parent Full thread

EduardoBautista

Things Ember Data's `findRecord` does:

* Checks if you already have the resource to prevent sending an unnecessary request (can be forced)

* Retrieves the resource based on a convention for the URL

* Parses the JSON based on a convention

* Stores the resource in the "store" for use in the app

Batching is also very simple thanks to a plugin from Netflix:

https://github.com/Netflix/ember-batch-request

The reason the Ember community doesn't talk about any of this stuff is because, from the developers perspective, nothing interesting happens, which is why developer productivity is high in Ember.

View on HN

Why would a UI framework know anything about records? Keep in mind that it's explicitly not React's goal to know anything about requests, routing, records, data, or anything like that. That's why you hear React people talking about how they achieve this stuff. Ember is a framework with a much larger scope, while React is a view layer.

Ember Data can be used separately from Ember itself. In fact, the official documentation treats them as if they are. It's even a separate project on GitHub:

https://github.com/emberjs/data

If even in Ember-land it's an entirely separate package, then why make the comparison to React at all..? (Ember + Ember Data) is more like (React + Apollo) then, no? But you're just comparing it to React without anything else.

My original comment said "React ecosystem", not just "React". Apollo is part of the ecosystem.

Here's what just sending a request looks like with React + Apollo: 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. :)

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

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 (although not the strategy I used... I don't think Apollo even existed yet at the time)

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!

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?

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.

Ember’s HTMLBars is no more “building up code as a string” than jsx is.

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

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?

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.

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?

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.

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

Just a counterpoint, but we've had a lot of pain with Ember, especially Ember Data, with only senior developers working on an app - figuring out the right areas to modify to implement a feature/bug fix was unnecessarily difficult, and some of the recommendations we got from those closely aligned with Ember (including from a former core dev) from a maintainability perspective were highly suspect.

We ended up switching to React by rewriting the Ember app in a few weeks and moving significantly faster as a team, gaining more flexibility & better abstractions (which we had to write, but it was not a problem with our engineers' quality). Since then, my whole organization has only written new UIs using React to my knowledge.

I personally would rather use Angular (latest) or React than use Ember again. I do appreciate some of the things Ember has brought to the ecosystem though like a robust CLI ala Rails, but I think the routing convention needs more flexibility and Ember Data needs some love to fix the ease of getting into some buggy situations.

I’m a big fan of Ember but Ember Data is just completely unusable for me once you start getting into relationships. Say you have a blog post with many comments. Creating a new Comment ends up sending an UPDATE request to the Post model with ALL the comments in an array. It’s crazy.

Reply on news.ycombinator.com