Maybe I am in the minority, but writing boilerplate code all the time just isn't something that interests me.
But mostly I'm curious how your point relates to this blog post. Maybe you can clarify? The stuff they're doing with Apollo here that potentially comes across as boilerplate also gets query batching, caching, refetching, etc. for free (in addition to the fancy stuff they also talk about like automatic mocks). It's not like they're "just sending a request." Maybe you can show me how you do all that in another framework without some setup/wrappers/etc.?
* 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.
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. :)
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)
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?
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?
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.
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.
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
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.
For example: let's say when component A or component B get rendered, they need to fetch users in order to show something about them. You only want to make the request if either of these components is actually rendered on the screen. What if they both get rendered? Is something going to know to reuse the inflight request so you don't have two identical requests? Or is it just naively going to make unnecessary requests? What if some other thing already fetched the user list earlier, are either of them still going to make the request anyway? Or use the data that's already there?
Another example: you've got your result from the users endpoint. Now you fetch some user information from the "blog author" endpoint. Information about the same user is in both responses. What's the authoritative client-side source of information about that user now? Are you now going to potentially be displaying stale/conflicting info about that user in 2+ different places?
etc.
You can always just keep things simple if you want, and people in React and GraphQL land are happy to do that, too. But a lot of people are also focused on building complex applications. This is just to give you some perspective on the "why" here.
For (2), the complexity is still there, just in the parent: it needs an entity store and to merge/invalidate when the same entity appears in multiple responses. So still not just a simple case of making some REST API calls.
Well, usually parent decides whether the children will be rendered or not.
I really don't see what GraphQL has to do with this problem. What you're describing are issues that pop up with any external datastore. GraphQL is just a protocol. If there are clients that take care of that type of caching, that's an implementation detail. You can also have REST clients that do the same.
> Are you now going to potentially be displaying stale/conflicting info about that user in 2+ different places?
If you knew you needed info about the user as a blog author as well, you could've included that in the users request. Isn't that what you would've done in GraphQL anyway?
I'm not trying to detract from GraphQL's usefulness, but you can accomplish the same things in REST pretty easily too, especially if you control both server and client code.
IMO, GraphQL really shines when you're implementing clients for APIs that you don't already control. In that case, the flexibility is great. But if you're building both the APIs and the clients, REST works (and has worked) pretty easily.
React Hooks (currently in alpha for the next release of React) finally clean up that component lifecycle complexity I think you're referring to. Nader Dabit has a great post [0] on how to use React Hooks with GraphQL.
[0]https://medium.com/open-graphql/react-hooks-for-graphql-3fa8...
Probably the OP has seen two many of those posts and doesn't have the right frame of reference to know what to do, and Apollo looks like the same.