Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Facebook Relay: An Evil And/Or Incompetent Attack on REST

pandastrike.com

Post reply on HN
Print view View original

51–60 of 166 posts

Re: Facebook Relay: An Evil And/Or Incompetent Attack on REST

#51

Post by qyv »

jtchang wrote: post #16

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…

> 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.

Re: Facebook Relay: An Evil And/Or Incompetent Attack on REST

#52

Post by neilellis »

hencq wrote: post #47

It's a shame that this article spends most of its time ranting and throwing around irrelevant attacks at Facebook (we get it, you don't like their product). If I buy the author's premise that REST does everything graphQL does and that everyone is just using REST wrong, please show us how to properly do it. Now I have to take the article's word for it, without any practical explanation how to correctly design a REST A…

I think there were some basic pointers in there, but yes I too would have liked some examples on how to do things better.

As much as I dislike people critiquing from a purist point, I also dislike my own ignorance on things that could keep my life simpler.

Re: Facebook Relay: An Evil And/Or Incompetent Attack on REST

#53

Post by falcolas »

Seems to me like the article and Relay are broken.

1) Why the new declarative query language for fetching attributes (columns) from objects (tables)?

2) Why build yet another transport mechanism on the top of HTTP, when there are so many to choose from already?

3) Oh, my god, boilerplate everywhere! What is this, Java?! /s

Seriously, though, the OP has some serious issues with Facebook, but to be fair Relay stinks badly of NIH. They had great success with React (a love letter to PHP), followed that with Flux (more of a design pattern than anything else), but this third attempt seems like it's trying too hard to create yet another data transport system.

Re: Facebook Relay: An Evil And/Or Incompetent Attack on REST

#54

Post by mecameron »

Two biggest issues: 1. This just reeks of "No true Scotsman". My biggest issue with this REST purist rhetoric is that it seems no one can actually implement REST, but apparently if someone could it would solve most/all of our problems. But after many years of smart people unable to implement REST properly according to these critics, then maybe the problem is with REST.

2. "If you implement REST, you use content negotiation, and thereby eliminate versioning and typing issues"

The author is conflating the issue of identifying a client version and actually responding with appropriate client specific version data. It's one thing to identify which version via some mechanism (e.g. URL, query string, content type), but you still need the latest code to handle all of the versions you want to support. The author seems to believe that that using content type will solve both problems, whereas the real problem is actually having an implementation that responds with the right client specific data and not break between releases.

Re: Facebook Relay: An Evil And/Or Incompetent Attack on REST

#55

Post by api »

jtchang wrote: post #16

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…

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.

Re: Facebook Relay: An Evil And/Or Incompetent Attack on REST

#56

Post by neilellis »

eggie wrote: post #49
dustingetz wrote: post #13

Here's a quote which I think well describes Facebook's stance on REST, before GraphQL and Relay were public. This is the idea that motivated GraphQL and Relay. "REST does a shitty job of efficiently expressing relational data. ... I mean REST has its place. For example, it has very predictable performance and well-known cache characteristics. The problem is when you want to fetch data in repeated rounds, or when you…

A query on a graph or a tree can both be RESTful. You can describe traversals of the graph or tree in a query embedded in an HTTP endpoint. You don't need to make repeated round trip queries to do the traversal unless you are unwilling to use a suitable query description. Metaphorically this is all pretty funny becuase the web is already a graph at a fundamental level.

LOL, yes that is a very good point. And how does the web solve this, by reference :-) Which is of course how you always solve cyclical graph representations in my (for sure limited) experience.

Re: Facebook Relay: An Evil And/Or Incompetent Attack on REST

#57

Post by bantunes »

The Web and HTTP were designed as support systems for a set of hyper-linked documents. Javascript came much later, and it's of little surprise to me that devs are having a hard time figuring out how to make them work together. The article is FUD, but some points are worth a read.

Re: Facebook Relay: An Evil And/Or Incompetent Attack on REST

#58

Post by SideburnsOfDoom »

thomasahle wrote: post #4

> a REST endpoint can return whatever you want. If you only want a subset of that graph, make an endpoint around that subset. So we have to make endpoints around every possible subset? > You want to avoid large object graphs anyway, for two reasons. Returning coarse-gained chunks of data tends to work against effective caching strategies, whether you're using REST, Relay, or anything else. You have to cache the whole…

> So we have to make endpoints around every possible subset?

No, you make endpoints for what clients actually need and use.

qyv has it right https://news.ycombinator.com/item?id=10413950 - responses are UI models and when you "model the problem domain of the UI layer" you're asking "which chunks of data do clients really need?"

If you really have clients that ask for "every possible subset" then this is a requirement that is completely unrelated to REST. i.e. you can try at solving it with REST, or without REST. The article actually says that: "If you're requesting some subset of a complicated object graph, and constantly re-negotiating which particular subset, then you have a problem which has nothing to do with REST."

Re: Facebook Relay: An Evil And/Or Incompetent Attack on REST

#59

Post by williamcotton »

jtchang wrote: post #16

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…

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

Re: Facebook Relay: An Evil And/Or Incompetent Attack on REST

#60

Post by sbov »

pixie_ wrote: post #45

I deal with REST zealots like this everyday :( just the fact that people spend so much time debating what is and what isn't REST should be a red flag that maybe it isn't the answer to everything. All the simple REST examples make it look like it is the perfect solution for CRUD tasks. But in reality API endpoints are not a straight pass through to the database. An endpoint may do any combination of CRUD tasks, it can…

I agree with pretty much all of this.

We developed an API because we had desktop/mobile/website. They all use the same API. I call it REST-ish.

I can't see how people think returning 404 for a "this product doesn't exist" is defensible. You now have two different things intertwined: this product doesn't exist (generally not a huge deal - what if an end user manually edits the url on your storefront?), and this url makes no sense (a huge deal - something is broken).

If you had code that threw the same exception when a product didn't exist vs when the table in your database doesn't even exist you would be ostracized. I don't see how it's somehow OK because it's REST.

Post reply on HN