Relay Technical Preview
facebook.github.io
facebook.github.io
This is so awesome. Much love to everyone at Facebook that has made this possible. With React, React Native, Rebound, GraphQL, Relay etc... You're saving us all from drowning in complexity when buiding web/mobile apps and I love it. Keep fighting the good fight.
Is Facebook also working with ClojureScript?
But inside the UI component you're really just defining the schema of the data to be returned from the server, you're actually implementing how to fetch that schema from the database somewhere else in your codebase.
Clojure 1.7 introduces a new file-type with extension .cljc that can load in both Clojure and ClojureScript. Which means you should be able to define both your React component AND the Server side implementation of the data fetching schema all from one file. Pretty frickin' cool if you ask me. One file, one component, that knows how to render itself, fetch it's data and serialize it's data.
Also, totally not okay with how FB mines data; they don't get a pass on that. Their OSS work is top notch, though. Now only if someone would take their own technology and beat them with it. A little guerilla warfare.
And it seems like you mean exactly the opposite of what you've said, based on that definition - you're not drinking the React Kool-Aid, or drinking the anti-React Kool-Aid.
I'm not trying to impose grammar OCD on anyone by any means. Like I implied, I'm probably one of the more ignorant people about these phrases. I just think it's confusing when people say things like "could care less" and "drinking Kool-Aid" when they actually mean the complete opposite. It's very bizarre to me but OTOH I guess it's fascinating that English is just that flexible.
Haven't you heard? There are tons of new JS framework being churned out annually, and each time it's hailed as the holy grail to all our problems.
Thanks. Nit-picking again, but drinking the Kool-Aid does mean "unquestioning, ... without criticism" implying that those who are drinking wouldn't have such reservations. That's what I was confused about. Oh well. Language is evolving, what else is new.
So it's not so much that they're praising highly in and of itself as that they're (implicitly) praising highly because they're buying the hype without questioning it, because it's not like they've used it in anger yet or heard 3rd party testimonials.
That said, he did use the phrase correctly, well, sort of. He was saying he believes in React, and then noted some caveats with people's reactions React. Which isn't properly "Drinking the Kool-Aid", but his meaning gets across.
> People have been saying tech X saves us from complexity for decades (OOP, noSQL, Knockout, Angular, etc...), and after a few years of use we realize it's not actually a magic bullet.
Throughout all your years of education, you were challenged the same amount. Doesn't mean you weren't doing/learning more.
X did save us from complexity. We just, continually, keep writing increasingly complex things.
Yesterday's sites were rendered on the server, with all state stored on the server. Today's are rendered on the client, buisness state on the server and rendering state stored on the client. Tomorrow's will distributedly store all data on the client; Think bit-torrent + encryption + web-rtc. Day After sites will be rendered on the server again; because we are now working with extremely "complex" 3D hologramed Apps.
But, I disagree with your last statement:
> Day After sites will be rendered on the server again; because we are now working with extremely "complex" 3D hologramed Apps.
Data is data is data. When the problem of distributing, syncing and querying data distributed between client and server is solved, it is solved forever for all classes of application which are built on that paradigm.
This is true whether you're rendering a 2D web page or a 3D holographic image from that data on the client. There would never be a need to go back to server management of data or state - that's why leaps forward in this space, which React is and now Relay looks like it will be, are incredibly exciting and pull the whole industry forward.
I would suggest a more likely 'Day After' problem would be managing more granular distribution of data and state through networks of clients, i.e. apps built on the peer-to-peer IoT paradigm rather than today's dominant client-server paradigm.
I think we agree on everything. I was honestly just being coy with "Day After". I don't believe I can adequately predict tomorrow's complexity issues. I just picked something arbitrarily "complex", not really giving it much thought.
Probably: s/coy/silly
React does save time. Maybe you've not built sufficiently complex apps in which state has bitten you in the ass, which isn't a bad thing. From experience, before React it was a nightmare as soon as the first dependency issues arose (whether that's data loading, UI flows or component hierarchies).
React's fundamentals are in managing state via composition and functional-like declerative programming; it's hard to argue that any other frameworks take this clean, pure approach and really solved the problem.
With Flux, Relay/GraphQL and ES7's decorators it's easier than ever to build pure, stateless components that are drop-in replacements for Angular's controller hell, or Marionette's awkward controllers.
I'm hoping Relay solves the data fetch problem in a way that makes isomorphic applications much cleaner.
Not if you use a server side templating engine that supports async rendering like MarkoJs [0][1].
[0] - https://marko-progressive-rendering.herokuapp.com/ [1] - https://github.com/marko-js/marko
Also I don't think the templating language has anything to do with the nature of blocking vs non-blocking data fetching.
But it's not. "className", much?
The React folks didn't make them up.
https://developer.mozilla.org/en-US/docs/Web/API/Element/cla...
They offer so much more context.
The previous commenter was specifically talking about the issue where the client side of an isomorphic application can "show the view with a 'loading' indicator", but generally the server is not able to stream out the full HTML until all data has been gathered and processed. The templating engine that I mentioned has a solution to that specific issue.
For example, in the first link, you can see that even though the template is rendered on the server, and has a data source with a 3 second delay, it does not prevent the rest of the template from being rendered and sent to the client, and includes a "loader"-like message (you could easily plop a loading gif in there instead of the textual message in the example).
So it does seem relevant to me.
<ul>
<for each="item in items">
<li>${item}</li>
</for>
</ul>
The Kadira team have even gotten Server-Side Rendering working with React [2][3] while no-one has yet for Blaze because the Blaze templates aren't currently available on the server due to how the bundler works. I'm sure MDG will make them available soon and then we'll be able to have SSR with both React and Blaze.
1. http://react-in-meteor.readthedocs.org/en/latest/
2. https://github.com/kadirahq/flow-router/tree/ssr
3. https://kadira.io/blog/meteor/meteor-ssr-support-using-flow-...
For those that want links:
AFAIK Falcor was announced just six months ago in spring 2015; I assume it is making progress towards a release. Relay wasn't based on it.
Falcor and Relay are conceptually similar but Relay is much more of a query engine, and Falcor isn't so much.
[1] https://plus.google.com/events/ca3l6qalpu0uqcce58a379006m0
The fact that these two companies came up with the same idea independently just reinforces how truly beneficial it must be.
I can't wait to try Om Next's implementation of this concept in my apps!
Nit: Google has been pretty generous in supporting developers outside the company. Eg., see Golang, Kubernetes, JS closure library, protofubf, bazel, and many more at github.com/google.
All I can say now is: ༼ つ ◕◡◕ ༽つ Got RELAY
https://github.com/facebook/relay/blob/master/examples/todo/...
It is ... massive!
Note: Not a design choice of Relay
Is that each Mutation file is redundant. Each Mutation file corresponds one - one with a component file. I think it does a big disservice to React itself (specifically JSX), which advocates for collocating View and Template because of cohesion.
Maybe its subjective.. and I can surely see the reasons for separating them, but I hope yungsters is reading this and collocates the mutations.
For Facebook we can write a single "like" mutation and share it between comments, posts, photos, etc.
That said, mutations in Relay are very powerful. This one does an optimistic update and handles inserting both the optimistic update and server response into the graph at the correct place. The fat query means that we can use the same mutation everywhere -- even across indifferent apps -- Relay only refetches the fields from the fat query that are used by the current view.
Look at the progression of flux talks, to a desire for isomorphic js (with flux), to fluxible app from yahoo, flummox, fluxor, alt.. and finally we get Redux, which is actually quite lean and a fairly clean abstraction with almost no boilerplate. Though arguably you can do a lot of it with RxJS alone.
I wouldn't surprise me that within two years we see something similar happen regarding Relay and GraphQL... for that matter, it wouldn't surprise me to see implementations that target specific database back ends easily. IE, you establish your object schemas, associate them to your db collections/tables, and establish filters based on client permissions. API/Service toolkits for data access using the protocol in question not the specific implementation necessarily.
When React came out, the core ideas were crystalline, and I was able to see the advantages in 5 minutes and to actually start doing something in 15. I would be happy to share the excitement for Relay... anyone care to explain? :-)
Here are some examples of things I do not understand.
The article below the video states that "By co-locating the queries with the view code, the developer can reason about what a component is doing by looking at it in isolation" but nowhere in the tutorial treasure hunt application I see this in action. There is a single React component called App, and I fail to see where it declares its data dependencies.
Moreover, according to the article, "Each component specifies its own data dependencies declaratively", but it seems that a core concept is that of mutation, which does not sound very declarative (although I am not sure I understand what that is exactly). The code for the mutation seems to access the this.props (which I assume live on the component). This looks like a cyclic dependency between components and mutations. The mutation also access a query over something called CheckHidingSpotForTreasurePayload which seems to be defined only in schema.json, although - if I understand correctly - that json is auto-generated.
All of this leaves me confused, which is why I was asking for a more conceptual explation. In other words: given the aims expressed in the article you linked (declarative data dependencies and so on), what is the reasoning that lead to the actual design of Relay?
I feel something that can be composed programmatically without having to deal with string concatenation like Falcor's queries or the Datomic Pull syntax proposed in Om Next [1] could be more flexible and robust. I may be missing something.
Sadly working as a consultant, using Relay as prescribed offers little use for me as I port from client to client with widely different data models. I am interested in maybe using Relay in parent React components to keep logical separation between my models and views.
https://www.reindex.io/blog/building-a-graphql-server-with-n...
The one caveat is that Relay's store is a representation of the data you've defined in GraphQL. So you can't use it to store data that shouldn't exist on the server. That's something we'd like to fix soon.
Do they have a specific PHP-to-Node bridge on the server side? If they write isomorphic code, either they are writing apps completely separate from PHP or they have some kind of integration (Node-in-PHP?) running?
I would be grateful for hints, I'm looking into working more with FB tech but I can't do Node on the server right now. Knowing how their architecture looks like with PHP/Hack on the backend would really help.
For server side rendering of the React app, they use https://github.com/reactjs/react-php-v8js (well they probably use a slightly customized version but this is what they open sourced).
Relay has a special server rendering mode that we created that I'm hoping to speak about soon. Until then I'm afraid I can't say more than that :)
Note: i'm mainly covering GraphQL
What i'm missing is implementations. For graphql you want a Java/python implementaion ready that can be hooked into your storage engine.
For iOS / Android you need some code generation tools that can generate your clientside business objects from the graphql schemas.
When i think about it, GraphQL combines the best of the SOAP/XML era (schemas, type safetype, client generation) with the new REST/JSON world (low footprint, simple structures).
However, it is still very difficult to adopt it. And most of the times, in a startup environment, you are faster implementing a rest api. And building your app on top of that. A schema (something like swagger, jsonschema) might help with client side code generation.
༼ つ ◕_◕ ༽つ Give RELAY
https://github.com/facebook/relay/commit/2a86be3e71cdc6511fa...
(For anyone who's interested here was our design: http://platform.qbix.com/guide/tools, http://platform.qbix.com/guide/messages)
Relay coalesces queries into batches for efficiency, manages error-prone asynchronous logic, caches data for performance, and automatically updates views as data changes.
Relay is also component-oriented, extending the notion of a React component to include a description of what data is necessary to render it. This colocation allows developers to reason locally about their application and eliminates bugs such under- or over-fetching data.
We do the same thing (we call it the getter and batcher pattern). See http://platform.qbix.com/guide/patterns
Briefly, the way it works is that you request a certain object, and don't have to worry about batching, throttling, caching, etc. You can also say "please call this function when all the following objects are fetched".
Our platform is also heavily based around events for which handlers are automatically unregistered when pages and tools are removed. So it's same as with facebook.
Plus we already support most of the following:
Offline support. This will allow applications to fulfill queries and enqueue updates without connectivity.
Real-time updates. In collaboration with the GraphQL community, we're working to define a specification for subscriptions and provide support for them in Relay.
A generic Relay. Just as the power of React was never about the virtual DOM, Relay is much more than a GraphQL client. We're working to extend Relay to provide a unified interface for interacting not only with server data, but also in-memory and native device data (and, even better, a mix of all three).
Finally, it's all too easy as developers to focus on those people with the newest devices and fastest internet connections. We're working to make it easier to build applications that are robust in the face of slow or intermittent connectivity.
BreezeJS is a stand-alone data library for SPAs which takes care of managing the lifecycle of data objects; querying, fetching, caching is all taken care of. Queries use OData by default
Any new framework these days has to bring a ton of innovation and performance to the table - is your framework faster and easier to use than React? Does it fulfill use cases that React cannot? How many more use cases can React fit than yours? Hint: There's React Canvas, React Native, React WinJS, and you can run it on your server. There's also approximately a billion modules for these libraries combined.
There are plenty of examples of projects that are DOA. If you want yours to be successful you'll REALLY have to sell it. Not that I'm rooting against you! :) If your library is more innovative and more powerful, more power to you! There's nothing wrong with progress. I'm just skeptical because the aforementioned libraries work for nearly 100% of companies.
now you should say "universal", "isomorphic" was a poor choice of words at first place and led to a lot of misunderstanding(and bad blood between js developers and mathematicians)
http://www.infoq.com/news/2015/08/netflix-universal-javascri...
> As applied to JavaScript, Charlie Robbins presented the idea in 2011. He called it "Isomorphic JavaScript" which has resulted in years of debate over the poor name. In recent months, the term Universal JavaScript has gained acceptance.
When someone says "isomorphic JS" I know exactly what they are talking about. I understand why some people might push back against it, but there's nothing wrong with the term.
No, that's how marketing works. We are developers not salesmen. and as computer scientists respecting other science branches is a duty. Using the expression "isomorphic" in that context is just confusing. And it makes developers sound like they haven't a fn clue what they are talking about.
Speak for yourself. Some of us are both.
and as computer scientists respecting other science branches is a duty. Using the expression "isomorphic" in that context is just confusing.
That's a fair point, but "context" is the key word. Using "isomorphic" incorrectly in a mathematical context would be one thing. But borrowing the word to use in a largely unrelated context seems fine to me. And it isn't like this is the first time a word has been borrowed and used to mean something "similar or related, but not quite the same". I'm pretty sure this has even happened inside other scientific disciplines, although I'll grant you that I don't have an example at my fingertips.
When you overload an existing term you make it more vague, thus destroying the precision of an abstraction.