Hacker News Reader

Comment by jtchang | Hacker News Reader

This article is a load of bullshit. When Facebook announced Relay it made immediate sense to me. The problem of fetching the right data from the backend is a pain in the ass for anyone that has built more than a simple todo app.

To me it is like sending a SQL query to the backend and instead of getting rows back you get objects nested in a way you specify.

The problem when using REST "correctly" is that the way your objects interrelate is not necessarily the same way on the backend as it is on the UI. So you end up creating custom REST endpoints for complicated UI that does not map directly to how your objects are related in the database.

This article has no substance in how they want to solve it besides just spouting "use REST correctly".

View on HN

> The problem when using REST "correctly" is that the way your objects interrelate is not necessarily the same way on the backend as it is on the UI. So you end up creating custom REST endpoints for complicated UI that does not map directly to how your objects are related in the database.

Not defending the article here, but I don't see this as a problem at all. Yes, you API objects should not necessarily map directly to your persistence layer; that is a good thing. The problem domains of the UI and the persistence layer are completely different and should therefore be modelled differently. Your API mediates between the two, acting like a repository for your UI models and abstracting away the persistence layer completely.

You are exactly correct about the role of the API here. A problem arises once you have multiple clients, each with different views, as well as different versions of those views. You can end up with a proliferation of API endpoints, each serving a custom view object for each different type of view, or you make your endpoints generic enough to serve all views, thus serving more data than any one view will ever use. You'll naturally have a tension between endpoint reusability and specific usefulness. The article actually seemed to have some of that tension itself, saying both "If you only want a subset of that graph, make an endpoint around that subset." and also "[Ad hoc endpoints] aren't REST", without giving any guidance as to how to make endpoints around arbitrary subsets of graph data without descending into being ad hoc. I'm not saying that you can't balance these with a good REST API, just that there is a real tension.

Right, you shouldn't feel like you are "sending a SQL query to the backend" as OP suggests. An API is an abstraction layer, you shouldn't have to know anything about the database to use it.

Actually, they mention using content type negotiation for versioning, content types as a type system, HTTP caching for speed and reducing the number of requests, and lots more solutions.

The article actually makes some well reasoned points, and I think poses a very good challenge to what Facebook are doing.

I don't think Facebook ever claimed that HTTP was insufficient. They claim that HTTP/REST does not scale in large and dynamic projects, and Relay/GraphQL solves some of those scaling concerns. Given how strongly Relay/GraphQL is resonating with developers, I would tend to agree that the raw HTTP way of solving these things (as you note above) are not good enough for the needs of most projects.

> They claim that HTTP/REST does not scale in large and dynamic projects

This is my point, the blog post has a good HTTP/REST based answer for all or most of the criticisms Facebook has of it, which I think poses a challenge to Facebook.

> Given how strongly Relay/GraphQL is resonating with developers

I'm inclined to avoid appeal to the majority, after all, PHP is very popular.

I think the appeal to majority goes the other way in this case. The article insists that existing technologies which dominate usage today (ie. HTTP) are good enough, and that Facebook's innovations are misguided. The authors have previously made similar claims about the DOM (vs. React). And after all, HTTP comprises of a far greater majority of server architectures than Relay/GraphQL does at the moment.

The versioning section of the article made absolutely no sense to me. Yes, HTTP has a mechanism to encode version info. He completely ignores Facebook's claim that dealing with that complicates server side code (because it has to distinguish between different versions), but goes on a rant that because they don't understand that the protocol allows to encode this (why ever Facebook's developers wouldn't realize this) they don't understand REST. No answer to how this magically makes the server side easier, completely ignoring what I think is the argument.

And really, most of that article feels like this. His facts are not wrong, but they don't match the claims they supposedly refute. Or if they do occasionally, it is drenched in so much rant-sauce that it gets covered up.

For those points to be well reasoned, one would have to assume that no one at Facebook has tried those things, though. If they really are integral to what REST is, then it doesn't really make sense that no one there knew what it was.

> For those points to be well reasoned, one would have to assume that no one at Facebook has tried those things, though.

Not quite. These points were well reasoned given the information Facebook has made public. If they have tried those things (which I fully expect them to have done), all that means is that there is an answer to these challenges.

To clarify: I expect that Facebook has a rebuttal to these points, however my guess would be that the rebuttal will be more Facebook specific than the motivation for these technologies that they specify publicly.

As much as I agree about your argument, that's going to be a problem no matter how you do it. You will always run into an impedance mismatch. The problem is, which area should drive the solutions of another area? You'll never get a "good" answer.

I see this as a good thing. In my mind, an API is made to be consumed from several different client, so it should make sense on it's own and not try to follow how objects are mapped onto one UI. However, it's also frequent to include "macro-endpoints" sided with regular routes to simplify a succession of common simple side-effects (like register and then login). That's not "correct" REST, but not a bad thing either.

Well slow down for a second...

The web is a big public, interconnected network of documents and links between them.

Relay is encouraging single-page applications that use private data and privileged authentication schemes. That is, you have to login with Facebook or create your own private authentication services. The state that you're requesting with with Relay and GraphQL and using to build your HTML is dependent on personalized data and doesn't have much to do with linking to public URLs.

You can most definitely use React to build static HTML and work within the context of HTTP verbs [0] [1], but it pulls you away from the Flux pattern. You don't really benefit much from Relay/GraphQL if you're building web applications based on an interconnected network of documents and links between them... REST is a great pattern for those kinds of applications.

But yeah, I definitely see how a combination of React, Flux and Relay/GraphQL would inherently push an agenda that has very little to do with HTTP and the public web. Not that there's anything wrong with this, as there are many valid use cases for the web browser beyond the original intentions of the web, but it is a good thing to keep in mind.

[0] https://github.com/williamcotton/universal-react

[1] https://github.com/williamcotton/browser-express

He also lost me when he attacked React. React makes developing web UIs sane. It's a web UI framework written by grownups who took a CS class. UI is a pure function of state. Why is that so hard?

The fact of the matter is this: the web was never designed to be a rich application UI. Web UIs of any kind are a hack on top of the web. By definition they are embracing and extending because they were never there in the original HTTP/HTML spec to begin with. They're so popular because deploying actual apps to endpoint devices is so horribly painful by comparison.

This guy also doesn't understand what true embrace/extend tactics look like. Embrace/extend/extinguish is when you embrace something, extend it, and then drag the market into a state where the use of other things becomes impossible. Nothing Facebook is doing is doing that to the web as far as I can see. Web sites that don't use React, Relay, etc. work just fine.

If anyone is doing E/E/E against the web it is Google with Chrome and all the complicated nasty standards (e.g. the WebRTC mess) that it's dragging everyone into that only Chrome implements well. But even there I think it's a weak argument. I use Safari and Firefox and the web works fine in those 99.9999% of the time.

I love when one engineer thinks he's smarter than ALL of the second largest Internet company's engineers put together--when he doesn't even have the context of working there to understand their reasoning. Clearly Facebook is evil and pays their employees solely to make us learn new technologies purely out of spite, not to improve their product better (which they get paid very well to do).

> This article is a load of bullshit.

Me and most people on the comments seem to agree, makes me wonder why is it on the top of the frontpage.

Reply on news.ycombinator.com