If you loved this post, I highly recommend this book! http://i.imgur.com/n4ogzt4.png
Facebook Relay: An Evil And/Or Incompetent Attack on REST
31–40 of 166 posts
Re: Facebook Relay: An Evil And/Or Incompetent Attack on REST
#32Sounds like the author spent a lot of time learning REST and is now mad at the risk of learning something else and throwing REST through the window :p
Re: Facebook Relay: An Evil And/Or Incompetent Attack on REST
#33There seems to be a lot of attacking the messenger rather than the message in these comments. Interesting.
I think because the tone of the article itself is so horrible. I honestly couldn't read it.
Re: Facebook Relay: An Evil And/Or Incompetent Attack on REST
#34I've spent many months over the past few years trying to really understand REST in order to design a good API and it never quite sat right - there was always something that seemed like a hack.
I'm not going to pick through the OP post, except this line:
"a REST endpoint can return whatever you want"
Yep. I know this and have done that: an endpoint to return complex data. And it never felt right - either I make a bunch of special endpoints losing all of the nice consistency of REST, or I have endpoints that return too much or too little. Or I have a highly parameterized endpoint that essentially lets me pass it a query (cough like GraphQL!)
At the start of the year, I was thinking about how I would like to write my applications client and what I (conceptually, I never got to implement it) came up with was rather similar in concept to Relay/GraphQL in that UI components declaratively state what data they are interested in and the system keeps it in sync by querying the server similar to how Relay/GraphQL do.
I personally find that model much nicer than REST.
But... as a consumer of third-party API's, I do love REST and worry about what a shift might do. However, from a SPA application development point of view, I love the concepts behind Relay and GraphQL more than REST.
But hey - I guess I just don't understand REST well enough (actually, I really don't - I'd be the first to admit it!), despite spending a long conscious effort in trying to. Which is the problem: this mythical "proper" REST seems too difficult to understand and use, so everyone kinda just makes up their own flawed flavour and calls it REST.
Re: Facebook Relay: An Evil And/Or Incompetent Attack on REST
#35Why is this upvoted so much? It's a complete strawman. Facebook's own intro at https://facebook.github.io/react/blog/2015/05/01/graphql-int... states: "There is actually much debate about what exactly REST is and is not. We wish to avoid such debates. We are interested in the typical attributes of systems that self-identify as REST, rather than systems which are formally REST." "We believe there are a number of weakn…
Read the whole article. The author addresses that exact quote.
Re: Facebook Relay: An Evil And/Or Incompetent Attack on REST
#36Facebook is not trying to kill REST. It just doesn't work well for their use-case. So, they make their own system that suits them better. What's wrong with that?
The point of the article is that Real REST does work well for these use cases (which is debatable, but that's what it says).
Re: Facebook Relay: An Evil And/Or Incompetent Attack on REST
#37Earlier quoted context omitted.
"So we have to make endpoints around every possible subset?" No, you use the query in querystring. One way or another you're offering a query interface. A lot of REST is just about how you offer the same interfaces you were planning on offering anyhow. Which is probably a source of a lot of the frustration REST advocates experience. If you're genuinely doing something that REST can't do very well, OK then, but if you…
> No, you use the query in querystring. Ok, but doing that straight on top of HTTP, will only cache queries that are exactly equal to previous ones. Not queries that are a subset of previous queries.
I think you have to be careful not to be too cavalier with the word "cache" there. While REST is sort of vaguely concerned with the ability to cache in the general sense, in real life we have to be specific about what is doing the caching. This is the sort of dynamic query you'd normally tell intervening proxies not to cache anyhow, so now we can reduce our concerns to the client and the server specifically. On the client, if it asked for a big chunk of the graph and now need to operate on a smaller on, I'd suggest that if the client does not want to incur another round trip, it would be incumbent on the client not to ask another question. (This is further backed up by a consistency concern; if I ask again, I may get a different answer because it has actually changed in the meantime. You may be better off with your code not even looking at the changes.) On the server, caching technologies can easily be arranged (if the server cares) to cache more granularly than is necessarily reflected in the answers. (In fact most of my "cloud" caches I'm currently responsible for do that all the time.)
I actually don't deny there's a use case here necessarily, but it may not be all that large, even to Facebook.
Re: Facebook Relay: An Evil And/Or Incompetent Attack on REST
#38I have to agree with this article. There is a tendency in tech to reinvent what we don't understand properly, and from experience of using third-party APIs (and from my own ignorance too) - HTTP is the thing we seem to know the least about (well actually one could argue TCP/IP is ...) I read this article from top to bottom and I didn't feel the comments were extreme or purist. It did leave me thinking we need to spen…
We could assume that, yes, everybody, Facebook included, just doesn't know REST (and implicitly assume that REST is an inherent good in the process). Or one could go "you know, Facebook has a lot of insanely smart people and their engineers are on record as having had problems with REST around stuff like complex object graphs and cycles, so maybe their solution is worth looking at."
If you have to say "oh, this thing is universally great, you all just don't understand it," I will bet hard against you at the first opportunity and I'll usually win in the process.
Re: Facebook Relay: An Evil And/Or Incompetent Attack on REST
#39This 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…
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.
Re: Facebook Relay: An Evil And/Or Incompetent Attack on REST
#40Earlier quoted context omitted.
> No, you use the query in querystring. Ok, but doing that straight on top of HTTP, will only cache queries that are exactly equal to previous ones. Not queries that are a subset of previous queries.
If the [data returned following a] query is a subset [of data points already returned] why do you need to get it again; if you actually need to re-retrieve it then it being cached is no use unless you dumped it from local cache mistakenly - that shouldn't be an often enough occurrence to need to cache the data. Or did I miss something?
I'm thinking about the case where you have a cache between you and the server, shared by multiple users.
I imagine this is useful at facebook, for example for loading parts of public peoples pages, etc.
You are right, that if the data is only used by you, you can just have an advanced cache in the client, sorting it out for you.