13 ms·

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

188 points by mwcampbell 11y ago

imjared 11y ago
fwiw, pandastrike seems to be on a crusade against all things Facebook/React so take this with a grain of salt. https://twitter.com/vjeux/status/655128064754499588 https://twitter.com/vjeux/status/655128064754499588
- jraines 11y ago
  It's all in the game: https://gettingreal.37signals.com/ch02_Have_an_Enemy.php https://gettingreal.37signals.com/ch02_Have_an_Enemy.php
bsimpson 11y ago
I have a problem taking seriously any article that spreads FUD by accusing their targets of spreading FUD. The people who build React and the related ecosystem are incredibly smart people trying to make the web better. I'm certain there's no ill-intent in their motives. Regardless, they open source pretty aggressively. If an open technology from Facebook displaces another open technology from another source, I don't understand why we should be upset simply because the backer of the more popular technique was Facebook.
- eropple 11y ago
  This site has a habit of doing that, it seems: https://twitter.com/vjeux/status/655128064754499588 https://twitter.com/vjeux/status/655128064754499588 The reasoning in all three of those posts feels super shallow; I have the most experience with React, and he's setting off a bunch of alarms in my head. "We don't need React because we have Web Components"--if Web Components were as high-perf ("they're getting faster so we don't need workarounds") or as just-plain-easy to work with (crickets!) even for a JavaScript dolt like me, maybe that'd be true. "But but open, but Facebook evil" is not a good-enough reason to use things that don't offer clear benefits. When Facebook twirls its evil mustachios and suddenly Embraces and Extends with...their...BSD-licensed software, I may worry. Somehow I'm not betting on that. (He might even have a good point about the tight coupling of React, except that React, and indeed all of my JavaScript, is the presentational layer, and anything important is behind the API anyway.)
- colbyh 11y ago
  Couldn't have said it better myself. I'm sure there are some great points in this post but I can't get over the obviously biased perspective (and borderline ad hominem attacks on FB).
- Mikushi 11y ago
  The web has been getting worst every year, mostly due to these companies spreading technologies to fix a web that is "broken" but who nobody but themselves complained about. I agree wholeheartedly with OP, Facebook & cie might have problems with certain components of the web, but they are neither broken or in need of a fix, that it doesn't fit their need sure, but their needs are, well, theirs. I can count on one hand the number of tech that came out in the past 5 or 6 years that are actually an improvement on the old if you are not Google or Facebook. What OP should have said may be is, stop trying to pass your problems as everyones problems. 99.9% of the web can function with the way the web was 5 years ago, if not more. Hell I was operating at high scale using standard stacks 7 years ago and I don't see why or how the situation has changed at all to warrant any of the bullshit technologies that are constantly touted as a fix. Developing for the web has become more of a nightmare than anything else because of the likes of Twitter, Facebook or Google pushing their stack on people who never needed it.
  - TazeTSchnitzel 11y ago
    Are Facebook actually passing their own problems as everyone's? They're making technologies which suit their needs better, and other people can use them too, but they're not forcing them on anyone.
- dustingetz 11y ago
  They appear to be middle-level freelancers, where convincing your clients that you are really smart and making a lot of noise in social media is more important than actually being really smart. (I am also a freelancer, so i'm not trying to be snarky so much as point out the incentives, the article is clearly not meant for HN)
- danpalmer 11y ago
  > If an open technology from Facebook displaces another open technology from another source, I don't understand why we should be upset simply because the backer of the more popular technique was Facebook. Facebook's future does not depend on the web being open, and in fact depends to some extent on it being quite a closed system. This makes them a poor choice of steward for core technologies in my opinion. I think the article's point is that the open technology from Facebook is a poor one in the wider context of the open web, and therefore if it does displace other models, that will slow us down and cause issues in the long run.
thomasahle 11y ago
> 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 chunk or nothing. I thought the whole point of Relay et al. was that it would cache the union of the chunks, such that when I request more data, it can download only the exact pieces I need?
- jerf 11y ago
  "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're doing something that HTTP can already do, why layer something else on top of HTTP that HTTP is already doing? (Sometimes there are good answers to that question, though.)
  - thomasahle 11y ago
    > 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.
    - pbhjpbhj 11y ago
      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?
      - 11y ago
devtique 11y ago
REST is one of the worst tech religions ever created yielding the most blinkered zealots. It's treated like a Bible where every word is taken as the Gospel truth that can't be tested, validated, compared or improved upon. Any alternative technology that reduces latency, improves performance and end user experience is considered an evil intrusion invalidating the purity of REST and must be vanquished. In the name of REST, practitioners give themselves a free-ticket to develop large, over-architected, dumb chatty high-latency solutions at the expense of the end user as long as tech choices are made within their interpretation of REST. Normally technology serves the client, unless you're a REST zealot in which case what the needs of the client is secondary, its more important to obtain Internet kudos points by forcing your way up the maturity ladder. No we must develop and shoe-horn all App and User experiences within the constraints of an ambiguous thesis that was built to link and update documents and create server-driven turn-by-turn apps. The fact they can't correctly interpret what different parts of REST means amongst themselves have generated programmer-decades worth of wasted discussions in the most useless bikeshed ever.
- steinnes 11y ago
  Well said. My blood boils thinking back to all the times I've heard "Yeah, but that's not REST." as a response to a perfectly reasonable and sane idea/suggestion.
- AdieuToLogic 11y ago
  REST is one of the worst tech religions ever created yielding the most blinkered zealots... Any alternative technology ... is considered an evil intrusion invalidating the purity of REST and must be vanquished. What a reasoned, sound, rational discourse. Good thing zealotry should be shat upon. No we must develop and shoe-horn all App and User experiences within the constraints of an ambiguous thesis that was built to link and update documents and create server-driven turn-by-turn apps. Wow. Pretty harsh, considering that the author of said "ambiguous thesis" is also one of the handful of people responsible for defining the very infrastructure which makes your diatribe possible to disseminate. Along with some guys named Tim[1] and Henrik[2]. Perhaps, instead of using this "shoe-horn-mandatin', ambiguous thesis thinkin', can't-force-their-ideas-on-everyone" HTTP "religion", you'd prefer whatever Facebook tells you is better? Oh, and ya might want to do that with something that doesn't use HTTP. Coz if you did, then u r p0wned by teh man. 1 - http://www.w3.org/People/Berners-Lee/ http://www.w3.org/People/Berners-Lee/ 2 - http://www.ietf.org/rfc/rfc1945.txt http://www.ietf.org/rfc/rfc1945.txt
empath75 11y ago
I'm not an expert on REST by any means, but it seems like that guy is sort of intentionally misrepresenting what they're doing. They didn't say Rest isn't good. They said that Rest isn't good for what they're doing with it. If you don't like it, don't use it.
michaelbuckbee 11y ago
An interesting comparison might be to something like sending protocol buffers over the wire instead of JSON [1]. You can make a 100% valid and spirited defense of JSON (human readable! lots of open source tooling!) which at Facebook's scale is trumped by "well it works 20% faster and we have 400 million users that will see the benefit". And that scale aspect of this really matters. OP is completely correct in the criticisms that X_NEW_THING can be done in REST, but with the number of users + infrastructure that Facebook is dealing with, small improvements can really matter. 1 - https://code.facebook.com/posts/872547912839369/improving-facebook-s-performance-on-android-with-flatbuffers/ https://code.facebook.com/posts/872547912839369/improving-fa...
deleted 11y ago
[deleted]
programminggeek 11y ago
There are PLENTY of problems with REST. You would be a fool to think Facebook is too stupid to understand why REST is perfect. If I were FB, I'd only feel compelled to use REST for a public API. Otherwise, I'd use the best tool for the job.
bjt 11y ago
I have a near-immediate distrust of anyone who says "you're all doing REST wrong." I've built my share of REST APIs. I've seen firsthand the tradeoff they face as more use cases are added, between letting the payload size keep creep upwards or exploding the number of endpoints. I like what GraphQL is doing to fix that. On the other hand I've never seen an API in the wild that I felt would really satisfy a REST purist. In theory, it'd be great to be able to stick a dumb HTTP cache in front of your app and have that solve all your performance and scalability problems. In practice, you have to sacrifice too much.
dustingetz 11y ago
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 want to fetch data that isn't expressed well as a hierarchy (think a graph with cycles -- not uncommon). That's where it breaks down. I think you can get pretty far with batched REST, but I'd like to see some way to query graphs in an easier way." -- Pete Hunt in 2013, when he worked at Facebook on React: https://news.ycombinator.com/item?id=7600565 https://news.ycombinator.com/item?id=7600565
- eggie 11y ago
  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.
  - neilellis 11y ago
    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.
  - dustingetz 11y ago
    The problem is that traversing a HATEOAS graph (like the www) requires a request at each edge. (The query is only the entry point to the graph, it doesn't help you traverse the graph. Relational joins make it so you don't need to traverse the graph, but this requires a lot of custom endpoints that bake in up-front knowledge about which nodes of the graph will need to be pre-fetched) edit: Either you edited or I misread, but "You can describe traversals of the graph or tree in a query embedded in an HTTP endpoint" - this is basically what GraphQL/Relay is: an easy way to do arbitrarily nested or recursive queries, like those you find in real complex applications. (Plug: I am a React consultant, hire me!)
wnevets 11y ago
There seems to be a lot of attacking the messenger rather than the message in these comments. Interesting.
- grokys 11y ago
  I think because the tone of the article itself is so horrible. I honestly couldn't read it.
jtchang 11y ago
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".
- wheaties 11y ago
  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.
- danpalmer 11y ago
  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.
  - glifchits 11y ago
    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.
    - danpalmer 11y ago
      > 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.
stupidcar 11y ago
By the time I finished this article, I hated the authors' superior, paranoid, whining tone so much I found myself hoping Facebook does destroy the open web just because it would annoy them.
TazeTSchnitzel 11y ago
Facebook 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?
- wmf 11y ago
  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).
  - TazeTSchnitzel 11y ago
    That's what the author is trying to say, but it comes off as defensive. Sure, REST probably can do these things, but by the sounds of things it's not ideal.
paultela 11y ago
One of the main advantages of Relay/GraphQL is that it lets front end devs iterate quickly without worrying about building new endpoints on the server side. Less context switching is a win when building out new features quickly.
programnature 11y ago
tl;dr: lol. The author is claiming Relay is a scheme to kill the open web. A simpler theory is just that Relay solves a problem Facebook (and many other people it seems) are having. The idea that REST has shortcomings for Facebook's use case is an unthinkable thought for the author. No argument is given for why we should consider REST to be a foundation of the open web. REST != HTTP. The post is full of logic-defying assertions like "Facebook wants to replace REST with Relay for the same reason they want to replace DOM engines with React Native."
neilellis 11y ago
I 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 spend more time learning and sharing knowledge of HTTP /REST than dismissing it. Of course, the headline is clickbait - and that is the only real criticism I had.
- eropple 11y ago
  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.
  - neilellis 11y ago
    A large group of smart people often produce some really dumb ideas, like 'Google Wave' - so I wouldn't personally use 'Proof by Large Group of Smart People' in this case. Hacker News has been the home of many a bad idea by smart folk. Instead, maybe we should all be critiquing the points raised. In my limited experience, most engineers (yes including very smart ones) are more enamoured with their own ideas (and not discounting myself here!) than learning other people's work well. And the critique I read didn't seem unfair in that respect, more so it encouraged me to look deeper at HTTP first before I add something into my apps own protocols. Which to me is a good thing. Especially around content negotiation which I had not looked at beyond a superficial understanding. For the record I ain't no purist :-)
    - s73v3r 11y ago
      Right, but if your argument is that they just didn't understand REST, and yet they employ some of the smartest people around, so if they can't understand REST, what chance do the rest of us have?
usaar333 11y ago
Why 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-introduction.html 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 weakness in typical REST systems" The author of this article is talking about REST in general, while Facebook specifically is talking about typical implementations of it.
- Cakez0r 11y ago
  Read the whole article. The author addresses that exact quote.
- _delirium 11y ago
  To me that's a weaker point of page. I'd rather read about why Facebook couldn't design a REST API that meets their needs, not why some sampling of "typical" REST APIs in the wild doesn't have the characteristics they want. Sure, they might not, but can FB build a REST API that does have the characteristics they want? The answer could still be no, of course.
drcode 11y ago
If you loved this post, I highly recommend this book! http://i.imgur.com/n4ogzt4.png http://i.imgur.com/n4ogzt4.png
gosukiwi 11y ago
Sounds 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
dkersten 11y ago
I'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.
- keithwhor 11y ago
  "REST" as we've come to know it is just a useful design pattern for APIs. That's it. It's not a law. You probably don't lack understanding of REST, every developer just has their own interpretation of edge cases (multi-resource responses, etc.) and different experience with what's worked and what hasn't. I wouldn't get caught up in the details. Use whatever tool is appropriate to solve your problem(s). I think it's likely we'll find certain design patterns (GraphQL vs. REST) are best suited to projects with specific problem spaces or scope. Maybe it's always best to start out "RESTful" and begin migrating to a different interface as your app scales in complexity. Maybe the latter problem is only an issue with medium or larger projects. Perhaps it's best to teach developers to be strict with REST to develop good habits and start migrating away once they're confident and comfortable with their ability to make architectural decisions. Either way --- don't sweat it. Experiment with what you like because you're the creator. Figure out what works best for you, and you'll be able to identify wins and challenges and decide for yourself how to use the technologies around you and what they bring to the table.
alexmuro 11y ago
Jafar Husain does an excellent job of explaining some of the problems netflix has had with REST APIs and why you might want to take a different approach in his introduction to Falcor video. Falcor is tackling some of the same problems as graphql / relay but making trade offs at different points. https://netflix.github.io/falcor/starter/why-falcor.html https://netflix.github.io/falcor/starter/why-falcor.html A REST API may be the best decision for a lot of projects but GraphQL and Falcor are solving interesting problems that come up more and more in single page apps of increasing complexity.
- Mickydtron 11y ago
  It's interesting to read the article with his presentation in mind. From a technical perspective, you should be able to just swap Netflix/Falcor in for Facebook/Relay in this article and have the arguments make about as much sense (They are both graphQL adjacent approaches to APIs that explicitly abandon RESTful principles). However, it seems to me that the article would be way less persuasive or interesting if you did that, because a lot of the intended force of the article relies on the premise "Facebook is evil", rather than the technology at hand. However, using "Facebook is evil" to prove "This thing that Facebook is doing is evil" is way less interesting than showing the latter just from technical details.
btown 11y ago
There are very key points about GraphQL/Relay that the author of this post is missing. For a Facebook user, all client-side cached data is stale. All of it. Posts are edited, profile pictures are changed (and those changes are referenced in other posts that must appear to be consistent with the image shown to the user). This is key to their value proposition - Facebook gives a new experience each time the user comes back to the site, thus the user will check the site multiple times a day. Now, you could cache if you could invalidate the caches... and this is fine to do on the server side, but it's downright impossible to push a client side cache invalidation at Facebook scale. Another key insight is that "HTTP can fire network requests in parallel" is insufficient if your requests are dependent on each other's results. Let's say you want to crawl a graph of nodes. Are you going to do a BFS with a full HTTP round trip at each level, collecting touched nodes and transmitting the border each time? When the latency of that round-trip is at 2G speeds? How would you handle this in REST, under the assumption (as above) that it's fine to let the server handle caching? Well, you might use the whole "HTTP's content types are a type system" concept that the author loves, and annotate your REST request with the structure of data you want back. UserWithPostsWithCommentsWithLikes is a type, after all, just as UserWithProfileInformation is a type. And at that point you don't want to name each of those separately; your Content-Type header would have some structure; it would almost read like a programming language. Oh, and you happen to have a server that can interpret that Content-Type piece by piece. You would eventually realize it's just more sane to break that out into the body of a POST request rather than holding on to REST just for REST's sake. And then, boom, you have GraphQL. The post devolves even further towards the end, making a dubious link between Facebook's developer tooling and its grander ambitions. Making realtime graph search, and realtime insights from the graph of entities, effortless to the developer and the user... that's one way in which the web is evolving. Every company needs to be able to think outside the box. If everyone took "don't reinvent the wheel" completely literally, we wouldn't have airplanes. Do I have gripes about the GraphQL syntax? Sure. Do I wish it was more like JSON Schema? Does grokking Relay migrations feel like reading a James Joyce novel? (With apologies.) Absolutely. But... are GraphQL/Relay a needed proposal to push innovation on the web forward? Yes.
pixie_ 11y ago
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't be type casted as a single one with a HTTP verb. Overloading HTTP error codes is another interesting problem. If the server returns 404 for a resource, what actually happened? Did the web server or my application return the 404. Conflating HTTP and application error codes leads to confusion. HATEOAS is just superfluous. I've met zealots who will defend it to the death. I just haven't found a practical use for it. Surface area and complexity are a big deal. REST encourages creating a CRUD interface for every single resource. I've met people who have created literally 100 endpoints upfront for a small application - how is that maintainable? I like that Facebook is standing up to the zealots. I get attacked at work when I try to create simple API endpoints and they aren't 100% REST (if anyone could agree what that even is.)
- sbov 11y ago
  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.
  - neilellis 11y ago
    HTTP error codes are something of an embarrassment to the web. We have more codes for April Fools jokes than some of our most common situations we deal with. We have some bizarrely specific codes like Payment Required and Requested Range Not Satisfiable yet almost all real world application responses get dumped into 400, 500 and a few other codes. How about more specific and useful codes like: Parameter not Supplied, Parameter Name Invalid, Parameter Value Invalid, Url Path Invalid Format, Could Not Parse Data etc. etc. This would also allow client libraries to decide better on how to process errors (i.e. as application or systemic errors). I'm sure folk have better suggestions than I but I can't imagine many folk genuinely feel these existing codes are expressive for the modern (API centric) web.
hencq 11y ago
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 API.
- neilellis 11y ago
  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.
yablak 11y ago
Can someone explain to me how Relay compares to gRPC?
falcolas 11y ago
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.
- drcode 11y ago
  > Why the new declarative query language for fetching attributes (columns) from objects (tables)? SQL isn't very composable- It was the right idea, but there's been a lot of progress in the last 50 years on how to traverse a database. It is all string-based, and it lacks a "pull syntax" (i.e. after the query completes, give me this graph-represented chunk of the result) > Why build yet another transport mechanism on the top of HTTP, when there are so many to choose from already? Relay is mostly agnostic on what mechanism is used to fetch results. > Oh, my god, boilerplate everywhere! What is this, Java?! /s Yeah, it's kind of awkward to do this stuff in Javascript- Look at what people are doing in more flexible languages, like here https://github.com/omcljs/om/wiki/Quick-Start-%28om.next%29 https://github.com/omcljs/om/wiki/Quick-Start-%28om.next%29
mecameron 11y ago
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.
bantunes 11y ago
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.
danpalmer 11y ago
Does anyone know of really good REST APIs? I feel like a lot of people talk about REST being better or worse than other technologies, but I haven't seen a single 'perfect example' of a REST API. If that's because it's impossible to make one, then that clearly tells us something, but I can't see any reason why we couldn't make one, it just seems that no one does. By "really good", I mean something that includes HATEOAS, versioning, uses content types correctly, utilises caching properly (probably HTTP 2 only with server-push, but still), etc etc.
TheCoelacanth 11y ago
Complete strawman. Facebook is quite clear that GraphQL is designed to address weaknesses in REST as it is typically implemented, not weaknesses in the actual concept of REST. > We are interested in the typical attributes of systems that self-identify as REST, rather than systems which are formally REST.
forrestthewoods 11y ago
Sometimes an API can do something, but doesn't it make it easy. An alternative that makes it easy isn't just a little valuable, it's a lot a valuable. This also applies to correctness. An API that can do something may be a bit of smashing a square peg through a round hole. An alternative that is round peg through a round hole is much better. I don't know enough to say what this situation looks like.
philjackson 11y ago
The tone of that article doesn't make me want to join their team...
catshirt 11y ago
in 6 years here this is the first post i felt compelled to comment on without even reading the article. the comments here reinforce my decision... if you have read the GraphQL docs, and built a sufficiently complex REST API, there is literally, technically speaking, no way to support this claim. still i skimmed the article... it must be satire.
glifchits 11y ago
These people have been attacking Facebook for a long time now. First React, and now Relay/GraphQL. Their technical arguments were never strong. Claiming that existing technologies eg. DOM, HTTP/REST are good enough is not convincing (disclosure: I very much so buy Facebook's arguments). But do they have a point in saying that Facebook is trying to control the web stack? I believe that Facebook are working to make the web better as a whole, but is this naïve? A better web for everyone helps big players like Facebook. Hopefully one day Facebook doesn't slowly start to close off these huge OSS projects.
intrasight 11y ago
Author says "they made a series of claims about why REST is broken" - without making "claims" be a hyperlink to those original claims. So this whole piece lacks semantic context and is therefore a fail.
- bmn_ 11y ago
  You are mistaken. Near the end there is a hyperlink to the claims document. It is titled "Facebook's terrible post" and points to the URL <https://facebook.github.io/react/blog/2015/05/01/graphql-introduction.html> https://facebook.github.io/react/blog/2015/05/01/graphql-int....
aikah 11y ago
While I'm anti Relay/GraphQL/co , I see a problem right here : > Blaming REST For The Non-RESTfulness Of Fake "REST" As I said in another thread here, people don't get what REST is because the original paper has done (IMHO) a poor job as explaining what it is about,masking simple concepts behind complicated sentences (academia style). Instead of being pedantic,arrogant and borderline insulting , which is unnecessary to make a point, it would be simpler and more useful to say that it is just about taking advantage of "natural" HTTP features and some web concepts such as hyperlinks. So there is no such thing as "fake REST" if one's intent is exactly that. Me not using content negotiation for API versioning doesn't my API fake REST. Too bad because the OP makes a few interesting points , but they are drown into some hateful garbage.
- bmn_ 11y ago
  > the original paper has done (IMHO) a poor job as explaining what it is about Please read <http://roy.gbiv.com/untangled/2008/specialization> http://roy.gbiv.com/untangled/2008/specialization>. The paper is for experts. Non-experts can learn from a suitable technology book instead.
juandazapata 11y ago
This article is implying that a group of the best engineers of the world (Facebook and Netflix engineers came up with similar solutions with Relay and Falcor), are just dumb and don't know how the web works. There are motivations behind those solutions, and are documented across videos, papers and documentation. It seems to me, that the author is ignoring the previous experience of such teams.
carsongross 11y ago
How did this article get flag killed? I wanted to say something constructive about the topic: Any time you layer an arbitrary UX over a given data model, expressiveness is absolutely necessary in the protocol in order to minimize round trips. This is why SQL has been so successful on the server side. An alternative to the "moving the whole graph to the client side" approach is the intercooler.js way [http://intercoolerjs.org/ http://intercoolerjs.org/]: HTTP requests express UI/UX needs, rather than generalized data queries to support a client-side object graph and model. This eliminates a whole swath of complex issues that come up with managing multiple instances of data in a distributed object graph environment, knocking system complexity down an order of magnitude.
- LukeB_UK 11y ago
  You should probably mention that you're the main contributor to intercooler.js. I've noticed quite a few comments from you plugging intercooler.js but with no mention of the fact that it's your project.
  - carsongross 11y ago
    Sure: I am the main contributor to intercooler.js, I use it every day in production and, when it is relevant to a given article, I mention it.
mvdanj 11y ago
Interesting how this article was #1 on HN a few hours ago and mysteriously disappeared. Conspiracy?
- carsongross 11y ago
  Flag killed. The unanimity of the commentary on the article (which was ranty, but had some reasonable points to make) is disturbing as well. No one is willing to take the other side of the argument?
  - bmn_ 11y ago
    There was apparently only a 30 minute window to do so. HN moves too fast for nuanced counter-replies to the commentary. If I just made a top-level comment, it would say something along "I agree in broad strokes", which is not that useful.
    - carsongross 11y ago
      And, from the looks of it, you would have been downvoted into oblivion for your trouble. So there was a zerg rush of negative ad hominem on the article and then it was flag killed despite being a reasonable technical topic to discuss. Good times, good times.
wahsd 11y ago
I find it rather problematic that this story moved from within the top 10 posts down to currently 78 in a matter of a couple of minutes. ..... Not that anyone will see this now. Facebook is an evil company headed by a psychopath that has said he wants to replace at the very least what people perceive to be the internet. You are killing the internet with every single thing you do on or with Facebook.

188 points by mwcampbell 11y ago

fwiw, pandastrike seems to be on a crusade against all things Facebook/React so take this with a grain of salt. https://twitter.com/vjeux/status/655128064754499588 https://twitter.com/vjeux/status/655128064754499588

jraines 11y ago
It's all in the game: https://gettingreal.37signals.com/ch02_Have_an_Enemy.php https://gettingreal.37signals.com/ch02_Have_an_Enemy.php

bsimpson 11y ago

I have a problem taking seriously any article that spreads FUD by accusing their targets of spreading FUD. The people who build React and the related ecosystem are incredibly smart people trying to make the web better. I'm certain there's no ill-intent in their motives. Regardless, they open source pretty aggressively. If an open technology from Facebook displaces another open technology from another source, I don't understand why we should be upset simply because the backer of the more popular technique was Facebook.

eropple 11y ago
This site has a habit of doing that, it seems: https://twitter.com/vjeux/status/655128064754499588 https://twitter.com/vjeux/status/655128064754499588 The reasoning in all three of those posts feels super shallow; I have the most experience with React, and he's setting off a bunch of alarms in my head. "We don't need React because we have Web Components"--if Web Components were as high-perf ("they're getting faster so we don't need workarounds") or as just-plain-easy to work with (crickets!) even for a JavaScript dolt like me, maybe that'd be true. "But but open, but Facebook evil" is not a good-enough reason to use things that don't offer clear benefits. When Facebook twirls its evil mustachios and suddenly Embraces and Extends with...their...BSD-licensed software, I may worry. Somehow I'm not betting on that. (He might even have a good point about the tight coupling of React, except that React, and indeed all of my JavaScript, is the presentational layer, and anything important is behind the API anyway.)
colbyh 11y ago
Couldn't have said it better myself. I'm sure there are some great points in this post but I can't get over the obviously biased perspective (and borderline ad hominem attacks on FB).
Mikushi 11y ago
The web has been getting worst every year, mostly due to these companies spreading technologies to fix a web that is "broken" but who nobody but themselves complained about. I agree wholeheartedly with OP, Facebook & cie might have problems with certain components of the web, but they are neither broken or in need of a fix, that it doesn't fit their need sure, but their needs are, well, theirs. I can count on one hand the number of tech that came out in the past 5 or 6 years that are actually an improvement on the old if you are not Google or Facebook. What OP should have said may be is, stop trying to pass your problems as everyones problems. 99.9% of the web can function with the way the web was 5 years ago, if not more. Hell I was operating at high scale using standard stacks 7 years ago and I don't see why or how the situation has changed at all to warrant any of the bullshit technologies that are constantly touted as a fix. Developing for the web has become more of a nightmare than anything else because of the likes of Twitter, Facebook or Google pushing their stack on people who never needed it.
- TazeTSchnitzel 11y ago
  Are Facebook actually passing their own problems as everyone's? They're making technologies which suit their needs better, and other people can use them too, but they're not forcing them on anyone.
dustingetz 11y ago
They appear to be middle-level freelancers, where convincing your clients that you are really smart and making a lot of noise in social media is more important than actually being really smart. (I am also a freelancer, so i'm not trying to be snarky so much as point out the incentives, the article is clearly not meant for HN)
danpalmer 11y ago
> If an open technology from Facebook displaces another open technology from another source, I don't understand why we should be upset simply because the backer of the more popular technique was Facebook. Facebook's future does not depend on the web being open, and in fact depends to some extent on it being quite a closed system. This makes them a poor choice of steward for core technologies in my opinion. I think the article's point is that the open technology from Facebook is a poor one in the wider context of the open web, and therefore if it does displace other models, that will slow us down and cause issues in the long run.

thomasahle 11y ago

> 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 chunk or nothing. I thought the whole point of Relay et al. was that it would cache the union of the chunks, such that when I request more data, it can download only the exact pieces I need?

jerf 11y ago
"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're doing something that HTTP can already do, why layer something else on top of HTTP that HTTP is already doing? (Sometimes there are good answers to that question, though.)
- thomasahle 11y ago
  > 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.
  - pbhjpbhj 11y ago
    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?
    - 11y ago

devtique 11y ago

REST is one of the worst tech religions ever created yielding the most blinkered zealots. It's treated like a Bible where every word is taken as the Gospel truth that can't be tested, validated, compared or improved upon. Any alternative technology that reduces latency, improves performance and end user experience is considered an evil intrusion invalidating the purity of REST and must be vanquished. In the name of REST, practitioners give themselves a free-ticket to develop large, over-architected, dumb chatty high-latency solutions at the expense of the end user as long as tech choices are made within their interpretation of REST. Normally technology serves the client, unless you're a REST zealot in which case what the needs of the client is secondary, its more important to obtain Internet kudos points by forcing your way up the maturity ladder. No we must develop and shoe-horn all App and User experiences within the constraints of an ambiguous thesis that was built to link and update documents and create server-driven turn-by-turn apps. The fact they can't correctly interpret what different parts of REST means amongst themselves have generated programmer-decades worth of wasted discussions in the most useless bikeshed ever.

steinnes 11y ago
Well said. My blood boils thinking back to all the times I've heard "Yeah, but that's not REST." as a response to a perfectly reasonable and sane idea/suggestion.
AdieuToLogic 11y ago
REST is one of the worst tech religions ever created yielding the most blinkered zealots... Any alternative technology ... is considered an evil intrusion invalidating the purity of REST and must be vanquished. What a reasoned, sound, rational discourse. Good thing zealotry should be shat upon. No we must develop and shoe-horn all App and User experiences within the constraints of an ambiguous thesis that was built to link and update documents and create server-driven turn-by-turn apps. Wow. Pretty harsh, considering that the author of said "ambiguous thesis" is also one of the handful of people responsible for defining the very infrastructure which makes your diatribe possible to disseminate. Along with some guys named Tim[1] and Henrik[2]. Perhaps, instead of using this "shoe-horn-mandatin', ambiguous thesis thinkin', can't-force-their-ideas-on-everyone" HTTP "religion", you'd prefer whatever Facebook tells you is better? Oh, and ya might want to do that with something that doesn't use HTTP. Coz if you did, then u r p0wned by teh man. 1 - http://www.w3.org/People/Berners-Lee/ http://www.w3.org/People/Berners-Lee/ 2 - http://www.ietf.org/rfc/rfc1945.txt http://www.ietf.org/rfc/rfc1945.txt

empath75 11y ago

I'm not an expert on REST by any means, but it seems like that guy is sort of intentionally misrepresenting what they're doing. They didn't say Rest isn't good. They said that Rest isn't good for what they're doing with it. If you don't like it, don't use it.

michaelbuckbee 11y ago

An interesting comparison might be to something like sending protocol buffers over the wire instead of JSON [1]. You can make a 100% valid and spirited defense of JSON (human readable! lots of open source tooling!) which at Facebook's scale is trumped by "well it works 20% faster and we have 400 million users that will see the benefit". And that scale aspect of this really matters. OP is completely correct in the criticisms that X_NEW_THING can be done in REST, but with the number of users + infrastructure that Facebook is dealing with, small improvements can really matter. 1 - https://code.facebook.com/posts/872547912839369/improving-facebook-s-performance-on-android-with-flatbuffers/ https://code.facebook.com/posts/872547912839369/improving-fa...

deleted 11y ago

[deleted]

programminggeek 11y ago

There are PLENTY of problems with REST. You would be a fool to think Facebook is too stupid to understand why REST is perfect. If I were FB, I'd only feel compelled to use REST for a public API. Otherwise, I'd use the best tool for the job.

bjt 11y ago

I have a near-immediate distrust of anyone who says "you're all doing REST wrong." I've built my share of REST APIs. I've seen firsthand the tradeoff they face as more use cases are added, between letting the payload size keep creep upwards or exploding the number of endpoints. I like what GraphQL is doing to fix that. On the other hand I've never seen an API in the wild that I felt would really satisfy a REST purist. In theory, it'd be great to be able to stick a dumb HTTP cache in front of your app and have that solve all your performance and scalability problems. In practice, you have to sacrifice too much.

dustingetz 11y ago

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 want to fetch data that isn't expressed well as a hierarchy (think a graph with cycles -- not uncommon). That's where it breaks down. I think you can get pretty far with batched REST, but I'd like to see some way to query graphs in an easier way." -- Pete Hunt in 2013, when he worked at Facebook on React: https://news.ycombinator.com/item?id=7600565 https://news.ycombinator.com/item?id=7600565

eggie 11y ago
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.
- neilellis 11y ago
  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.
- dustingetz 11y ago
  The problem is that traversing a HATEOAS graph (like the www) requires a request at each edge. (The query is only the entry point to the graph, it doesn't help you traverse the graph. Relational joins make it so you don't need to traverse the graph, but this requires a lot of custom endpoints that bake in up-front knowledge about which nodes of the graph will need to be pre-fetched) edit: Either you edited or I misread, but "You can describe traversals of the graph or tree in a query embedded in an HTTP endpoint" - this is basically what GraphQL/Relay is: an easy way to do arbitrarily nested or recursive queries, like those you find in real complex applications. (Plug: I am a React consultant, hire me!)

wnevets 11y ago

There seems to be a lot of attacking the messenger rather than the message in these comments. Interesting.

grokys 11y ago
I think because the tone of the article itself is so horrible. I honestly couldn't read it.

jtchang 11y ago

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

wheaties 11y ago
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.
danpalmer 11y ago
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.
- glifchits 11y ago
  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.
  - danpalmer 11y ago
    > 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.

stupidcar 11y ago

By the time I finished this article, I hated the authors' superior, paranoid, whining tone so much I found myself hoping Facebook does destroy the open web just because it would annoy them.

TazeTSchnitzel 11y ago

Facebook 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?

wmf 11y ago
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).
- TazeTSchnitzel 11y ago
  That's what the author is trying to say, but it comes off as defensive. Sure, REST probably can do these things, but by the sounds of things it's not ideal.

paultela 11y ago

One of the main advantages of Relay/GraphQL is that it lets front end devs iterate quickly without worrying about building new endpoints on the server side. Less context switching is a win when building out new features quickly.

programnature 11y ago

tl;dr: lol. The author is claiming Relay is a scheme to kill the open web. A simpler theory is just that Relay solves a problem Facebook (and many other people it seems) are having. The idea that REST has shortcomings for Facebook's use case is an unthinkable thought for the author. No argument is given for why we should consider REST to be a foundation of the open web. REST != HTTP. The post is full of logic-defying assertions like "Facebook wants to replace REST with Relay for the same reason they want to replace DOM engines with React Native."

neilellis 11y ago

I 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 spend more time learning and sharing knowledge of HTTP /REST than dismissing it. Of course, the headline is clickbait - and that is the only real criticism I had.

eropple 11y ago
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.
- neilellis 11y ago
  A large group of smart people often produce some really dumb ideas, like 'Google Wave' - so I wouldn't personally use 'Proof by Large Group of Smart People' in this case. Hacker News has been the home of many a bad idea by smart folk. Instead, maybe we should all be critiquing the points raised. In my limited experience, most engineers (yes including very smart ones) are more enamoured with their own ideas (and not discounting myself here!) than learning other people's work well. And the critique I read didn't seem unfair in that respect, more so it encouraged me to look deeper at HTTP first before I add something into my apps own protocols. Which to me is a good thing. Especially around content negotiation which I had not looked at beyond a superficial understanding. For the record I ain't no purist :-)
  - s73v3r 11y ago
    Right, but if your argument is that they just didn't understand REST, and yet they employ some of the smartest people around, so if they can't understand REST, what chance do the rest of us have?

usaar333 11y ago

Why 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-introduction.html 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 weakness in typical REST systems" The author of this article is talking about REST in general, while Facebook specifically is talking about typical implementations of it.

Cakez0r 11y ago
Read the whole article. The author addresses that exact quote.
_delirium 11y ago
To me that's a weaker point of page. I'd rather read about why Facebook couldn't design a REST API that meets their needs, not why some sampling of "typical" REST APIs in the wild doesn't have the characteristics they want. Sure, they might not, but can FB build a REST API that does have the characteristics they want? The answer could still be no, of course.

drcode 11y ago

If you loved this post, I highly recommend this book! http://i.imgur.com/n4ogzt4.png http://i.imgur.com/n4ogzt4.png

gosukiwi 11y ago

Sounds 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

dkersten 11y ago

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

keithwhor 11y ago
"REST" as we've come to know it is just a useful design pattern for APIs. That's it. It's not a law. You probably don't lack understanding of REST, every developer just has their own interpretation of edge cases (multi-resource responses, etc.) and different experience with what's worked and what hasn't. I wouldn't get caught up in the details. Use whatever tool is appropriate to solve your problem(s). I think it's likely we'll find certain design patterns (GraphQL vs. REST) are best suited to projects with specific problem spaces or scope. Maybe it's always best to start out "RESTful" and begin migrating to a different interface as your app scales in complexity. Maybe the latter problem is only an issue with medium or larger projects. Perhaps it's best to teach developers to be strict with REST to develop good habits and start migrating away once they're confident and comfortable with their ability to make architectural decisions. Either way --- don't sweat it. Experiment with what you like because you're the creator. Figure out what works best for you, and you'll be able to identify wins and challenges and decide for yourself how to use the technologies around you and what they bring to the table.

alexmuro 11y ago

Jafar Husain does an excellent job of explaining some of the problems netflix has had with REST APIs and why you might want to take a different approach in his introduction to Falcor video. Falcor is tackling some of the same problems as graphql / relay but making trade offs at different points. https://netflix.github.io/falcor/starter/why-falcor.html https://netflix.github.io/falcor/starter/why-falcor.html A REST API may be the best decision for a lot of projects but GraphQL and Falcor are solving interesting problems that come up more and more in single page apps of increasing complexity.

Mickydtron 11y ago
It's interesting to read the article with his presentation in mind. From a technical perspective, you should be able to just swap Netflix/Falcor in for Facebook/Relay in this article and have the arguments make about as much sense (They are both graphQL adjacent approaches to APIs that explicitly abandon RESTful principles). However, it seems to me that the article would be way less persuasive or interesting if you did that, because a lot of the intended force of the article relies on the premise "Facebook is evil", rather than the technology at hand. However, using "Facebook is evil" to prove "This thing that Facebook is doing is evil" is way less interesting than showing the latter just from technical details.

btown 11y ago

There are very key points about GraphQL/Relay that the author of this post is missing. For a Facebook user, all client-side cached data is stale. All of it. Posts are edited, profile pictures are changed (and those changes are referenced in other posts that must appear to be consistent with the image shown to the user). This is key to their value proposition - Facebook gives a new experience each time the user comes back to the site, thus the user will check the site multiple times a day. Now, you could cache if you could invalidate the caches... and this is fine to do on the server side, but it's downright impossible to push a client side cache invalidation at Facebook scale. Another key insight is that "HTTP can fire network requests in parallel" is insufficient if your requests are dependent on each other's results. Let's say you want to crawl a graph of nodes. Are you going to do a BFS with a full HTTP round trip at each level, collecting touched nodes and transmitting the border each time? When the latency of that round-trip is at 2G speeds? How would you handle this in REST, under the assumption (as above) that it's fine to let the server handle caching? Well, you might use the whole "HTTP's content types are a type system" concept that the author loves, and annotate your REST request with the structure of data you want back. UserWithPostsWithCommentsWithLikes is a type, after all, just as UserWithProfileInformation is a type. And at that point you don't want to name each of those separately; your Content-Type header would have some structure; it would almost read like a programming language. Oh, and you happen to have a server that can interpret that Content-Type piece by piece. You would eventually realize it's just more sane to break that out into the body of a POST request rather than holding on to REST just for REST's sake. And then, boom, you have GraphQL. The post devolves even further towards the end, making a dubious link between Facebook's developer tooling and its grander ambitions. Making realtime graph search, and realtime insights from the graph of entities, effortless to the developer and the user... that's one way in which the web is evolving. Every company needs to be able to think outside the box. If everyone took "don't reinvent the wheel" completely literally, we wouldn't have airplanes. Do I have gripes about the GraphQL syntax? Sure. Do I wish it was more like JSON Schema? Does grokking Relay migrations feel like reading a James Joyce novel? (With apologies.) Absolutely. But... are GraphQL/Relay a needed proposal to push innovation on the web forward? Yes.

pixie_ 11y ago

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't be type casted as a single one with a HTTP verb. Overloading HTTP error codes is another interesting problem. If the server returns 404 for a resource, what actually happened? Did the web server or my application return the 404. Conflating HTTP and application error codes leads to confusion. HATEOAS is just superfluous. I've met zealots who will defend it to the death. I just haven't found a practical use for it. Surface area and complexity are a big deal. REST encourages creating a CRUD interface for every single resource. I've met people who have created literally 100 endpoints upfront for a small application - how is that maintainable? I like that Facebook is standing up to the zealots. I get attacked at work when I try to create simple API endpoints and they aren't 100% REST (if anyone could agree what that even is.)

sbov 11y ago
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.
- neilellis 11y ago
  HTTP error codes are something of an embarrassment to the web. We have more codes for April Fools jokes than some of our most common situations we deal with. We have some bizarrely specific codes like Payment Required and Requested Range Not Satisfiable yet almost all real world application responses get dumped into 400, 500 and a few other codes. How about more specific and useful codes like: Parameter not Supplied, Parameter Name Invalid, Parameter Value Invalid, Url Path Invalid Format, Could Not Parse Data etc. etc. This would also allow client libraries to decide better on how to process errors (i.e. as application or systemic errors). I'm sure folk have better suggestions than I but I can't imagine many folk genuinely feel these existing codes are expressive for the modern (API centric) web.

hencq 11y ago

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

neilellis 11y ago
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.

yablak 11y ago

Can someone explain to me how Relay compares to gRPC?

falcolas 11y ago

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.

drcode 11y ago
> Why the new declarative query language for fetching attributes (columns) from objects (tables)? SQL isn't very composable- It was the right idea, but there's been a lot of progress in the last 50 years on how to traverse a database. It is all string-based, and it lacks a "pull syntax" (i.e. after the query completes, give me this graph-represented chunk of the result) > Why build yet another transport mechanism on the top of HTTP, when there are so many to choose from already? Relay is mostly agnostic on what mechanism is used to fetch results. > Oh, my god, boilerplate everywhere! What is this, Java?! /s Yeah, it's kind of awkward to do this stuff in Javascript- Look at what people are doing in more flexible languages, like here https://github.com/omcljs/om/wiki/Quick-Start-%28om.next%29 https://github.com/omcljs/om/wiki/Quick-Start-%28om.next%29

mecameron 11y ago

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.

bantunes 11y ago

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.

danpalmer 11y ago

Does anyone know of really good REST APIs? I feel like a lot of people talk about REST being better or worse than other technologies, but I haven't seen a single 'perfect example' of a REST API. If that's because it's impossible to make one, then that clearly tells us something, but I can't see any reason why we couldn't make one, it just seems that no one does. By "really good", I mean something that includes HATEOAS, versioning, uses content types correctly, utilises caching properly (probably HTTP 2 only with server-push, but still), etc etc.

TheCoelacanth 11y ago

Complete strawman. Facebook is quite clear that GraphQL is designed to address weaknesses in REST as it is typically implemented, not weaknesses in the actual concept of REST. > We are interested in the typical attributes of systems that self-identify as REST, rather than systems which are formally REST.

forrestthewoods 11y ago

Sometimes an API can do something, but doesn't it make it easy. An alternative that makes it easy isn't just a little valuable, it's a lot a valuable. This also applies to correctness. An API that can do something may be a bit of smashing a square peg through a round hole. An alternative that is round peg through a round hole is much better. I don't know enough to say what this situation looks like.

philjackson 11y ago

The tone of that article doesn't make me want to join their team...

catshirt 11y ago

in 6 years here this is the first post i felt compelled to comment on without even reading the article. the comments here reinforce my decision... if you have read the GraphQL docs, and built a sufficiently complex REST API, there is literally, technically speaking, no way to support this claim. still i skimmed the article... it must be satire.

glifchits 11y ago

These people have been attacking Facebook for a long time now. First React, and now Relay/GraphQL. Their technical arguments were never strong. Claiming that existing technologies eg. DOM, HTTP/REST are good enough is not convincing (disclosure: I very much so buy Facebook's arguments). But do they have a point in saying that Facebook is trying to control the web stack? I believe that Facebook are working to make the web better as a whole, but is this naïve? A better web for everyone helps big players like Facebook. Hopefully one day Facebook doesn't slowly start to close off these huge OSS projects.

intrasight 11y ago

Author says "they made a series of claims about why REST is broken" - without making "claims" be a hyperlink to those original claims. So this whole piece lacks semantic context and is therefore a fail.

bmn_ 11y ago
You are mistaken. Near the end there is a hyperlink to the claims document. It is titled "Facebook's terrible post" and points to the URL <https://facebook.github.io/react/blog/2015/05/01/graphql-introduction.html> https://facebook.github.io/react/blog/2015/05/01/graphql-int....

aikah 11y ago

While I'm anti Relay/GraphQL/co , I see a problem right here : > Blaming REST For The Non-RESTfulness Of Fake "REST" As I said in another thread here, people don't get what REST is because the original paper has done (IMHO) a poor job as explaining what it is about,masking simple concepts behind complicated sentences (academia style). Instead of being pedantic,arrogant and borderline insulting , which is unnecessary to make a point, it would be simpler and more useful to say that it is just about taking advantage of "natural" HTTP features and some web concepts such as hyperlinks. So there is no such thing as "fake REST" if one's intent is exactly that. Me not using content negotiation for API versioning doesn't my API fake REST. Too bad because the OP makes a few interesting points , but they are drown into some hateful garbage.

bmn_ 11y ago
> the original paper has done (IMHO) a poor job as explaining what it is about Please read <http://roy.gbiv.com/untangled/2008/specialization> http://roy.gbiv.com/untangled/2008/specialization>. The paper is for experts. Non-experts can learn from a suitable technology book instead.

juandazapata 11y ago

This article is implying that a group of the best engineers of the world (Facebook and Netflix engineers came up with similar solutions with Relay and Falcor), are just dumb and don't know how the web works. There are motivations behind those solutions, and are documented across videos, papers and documentation. It seems to me, that the author is ignoring the previous experience of such teams.

carsongross 11y ago

How did this article get flag killed? I wanted to say something constructive about the topic: Any time you layer an arbitrary UX over a given data model, expressiveness is absolutely necessary in the protocol in order to minimize round trips. This is why SQL has been so successful on the server side. An alternative to the "moving the whole graph to the client side" approach is the intercooler.js way [http://intercoolerjs.org/ http://intercoolerjs.org/]: HTTP requests express UI/UX needs, rather than generalized data queries to support a client-side object graph and model. This eliminates a whole swath of complex issues that come up with managing multiple instances of data in a distributed object graph environment, knocking system complexity down an order of magnitude.

LukeB_UK 11y ago
You should probably mention that you're the main contributor to intercooler.js. I've noticed quite a few comments from you plugging intercooler.js but with no mention of the fact that it's your project.
- carsongross 11y ago
  Sure: I am the main contributor to intercooler.js, I use it every day in production and, when it is relevant to a given article, I mention it.

mvdanj 11y ago

Interesting how this article was #1 on HN a few hours ago and mysteriously disappeared. Conspiracy?

carsongross 11y ago
Flag killed. The unanimity of the commentary on the article (which was ranty, but had some reasonable points to make) is disturbing as well. No one is willing to take the other side of the argument?
- bmn_ 11y ago
  There was apparently only a 30 minute window to do so. HN moves too fast for nuanced counter-replies to the commentary. If I just made a top-level comment, it would say something along "I agree in broad strokes", which is not that useful.
  - carsongross 11y ago
    And, from the looks of it, you would have been downvoted into oblivion for your trouble. So there was a zerg rush of negative ad hominem on the article and then it was flag killed despite being a reasonable technical topic to discuss. Good times, good times.

wahsd 11y ago

I find it rather problematic that this story moved from within the top 10 posts down to currently 78 in a matter of a couple of minutes. ..... Not that anyone will see this now. Facebook is an evil company headed by a psychopath that has said he wants to replace at the very least what people perceive to be the internet. You are killing the internet with every single thing you do on or with Facebook.