10 ms·

Relay Technical Preview

474 points by cpojer 11y ago

TheAceOfHearts 11y ago
The release commit is really the best: https://www.dropbox.com/s/9gx377scddhxo95/Screenshot%202015-08-11%2012.35.52.png?dl=0 https://www.dropbox.com/s/9gx377scddhxo95/Screenshot%202015-... All I can say now is: ༼ つ ◕◡◕ ༽つ Got RELAY
- falcor84 11y ago
  Just putting a live link to that commit here: https://github.com/facebook/relay/tree/2a86be3e71cdc6511fa994e3de539f72070da1b4 https://github.com/facebook/relay/tree/2a86be3e71cdc6511fa99...
stevebmark 11y ago
I'm really excited about this! While working on an "isomorphic" app, data fetching gets incredibly complicated. There are many edge cases. For example, when rendering on the server, you have to block all renders until all data fetching is complete. But on the client, you can show the view with a "loading" indicator, as in not block. But you only need to fetch data for that route on the client if it hasn't been fetched on the server...the rabbit hole is full of wheels you don't want to reinvent. I'm hoping Relay solves the data fetch problem in a way that makes isomorphic applications much cleaner.
- dsp1234 11y ago
  you have to block all renders until all data fetching is complete. Not if you use a server side templating engine that supports async rendering like MarkoJs [0][1]. [0] - https://marko-progressive-rendering.herokuapp.com/ https://marko-progressive-rendering.herokuapp.com/ [1] - https://github.com/marko-js/marko https://github.com/marko-js/marko
  - stevebmark 11y ago
    I'm spoiled by the niceness of JSX. It's a very clean and expressive and easy to read language, because it's only what I already know, Javascript and HTML. There are no APIs to learn (except for some minor cases, like inline comments). This template language looks like it would only have downsides compared to JSX. It's a new syntax to learn, and less expressive. This templating language even adds HTML-like attributes! What a mess. Also I don't think the templating language has anything to do with the nature of blocking vs non-blocking data fetching.
    - marcusarmstrong 11y ago
      it's only what I already know, Javascript and HTML But it's not. "className", much?
      - Nogs 11y ago
        http://www.w3schools.com/jsref/prop_html_classname.asp http://www.w3schools.com/jsref/prop_html_classname.asp
        marcusarmstrong 11y ago
        Sure. But that's different than <div className="blah">.
        smhg 11y ago
        Not much. These are actually the Web API attribute names you should use when accessing these attributes from a non-HTML language (e.g. JavaScript). The React folks didn't make them up.
        smhg 11y ago
        w3schools might have gotten a bit better lately, but please use MDN as a reference: https://developer.mozilla.org/en-US/docs/Web/API/Element/className https://developer.mozilla.org/en-US/docs/Web/API/Element/cla... They offer so much more context.
- sergiotapia 11y ago
  Meteor already does this. In your template (Blaze) you can wait for your subscriptions to be ready and in the meantime render a loading icon or something else. Check it out!
  - alanning 11y ago
    In this case, I think the more accurate example would be Meteor + React [1]. You can still show the "wait for data to be ready" state as you described. (For those interested, follow the linked tutorial.) 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/ http://react-in-meteor.readthedocs.org/en/latest/ 2. https://github.com/kadirahq/flow-router/tree/ssr https://github.com/kadirahq/flow-router/tree/ssr 3. https://kadira.io/blog/meteor/meteor-ssr-support-using-flow-router-and-react https://kadira.io/blog/meteor/meteor-ssr-support-using-flow-...
aikah 11y ago
> While working on an "isomorphic" app 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-javascript 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.
- stevebmark 11y ago
  Never.
- aaron-lebo 11y ago
  Words take on new, unintended, and incorrect meanings all the time. It's how language works. 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.
  - aikah 11y ago
    > Words take on new, unintended, and incorrect meanings all the time. It's how language works. 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.
    - lol_haha 11y ago
      https://en.wikipedia.org/wiki/History_of_the_English_language https://en.wikipedia.org/wiki/History_of_the_English_languag... might be a good starting point.
    - mindcrime 11y ago
      We are developers not salesmen 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.
AlwaysBCoding 11y ago
I'm totally cool with Facebook mining my data if their open source keeps up this pace. GraphQL + Relay are total game changers for structuring web + mobile applications. Code bases get cleaner and more reliable. Less data gets sent over the wire. Other cool libraries are going to be built on top of Relay (I'm pretty excited to see what can be done now with ClojureScript components in .cljc files). 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.
- graffitici 11y ago
  Can you expand on what you mean by "what can be done with ClojureScript components in .cljc files"? Is Facebook also working with ClojureScript?
  - petrbela 11y ago
    ClojureScript community is pretty close to React (see e.g. Om), and since React 0.13 supports plain classes, they can be written in CS. So FB itself might not be doing anything with CS but enables the CS community to work in the same ecosystem.
  - AlwaysBCoding 11y ago
    Well the whole idea of Relay is to couple together the rendering logic of a UI component with the data fetching requirement of the component. So if you change the rendering logic of the component, the data that is fetched from the server will also change with it and you'll never be over/under fetching data. 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.
picardo 11y ago
This is very exciting. Facebook's commitment to open source never ceases to impress me. They could keep this technology to themselves and have light years or we'd only read it in academic papers, like Google has done with its core technologies, and someone else would have to reverse engineer them. But Facebook gives the entire code base. No other large company I know of has such a strong commitment to open source.
- ThundaUp 11y ago
  Netflix has a pretty awesome open source library, they are worth checking out as well. https://netflix.github.io/ https://netflix.github.io/
  - curun1r 11y ago
    It's funny you should mention Netflix. They demoed something called Falkor two years ago that is/was extremely similar to Relay/GraphQL. It's unfortunate that it's made so little progress in the past two years, but it wouldn't surprise me of the talks on Falkor had influenced or inspired Facebook's implementation. For those that want links: https://twitter.com/falcorjs https://twitter.com/falcorjs http://moduscreate.com/falcor-mvc-for-an-asynchronous-world http://moduscreate.com/falcor-mvc-for-an-asynchronous-world https://www.youtube.com/watch?v=z8UgDZ4rXBU https://www.youtube.com/watch?v=z8UgDZ4rXBU
    - spicyj 11y ago
      > two years ago 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.
      - curun1r 11y ago
        You're mistaken. My first exposure to it was a talk at QCon in Nov 2013. It wasn't posted publicly online until Feb 2014, but here's the link: http://www.infoq.com/presentations/netflix-reactive-rest http://www.infoq.com/presentations/netflix-reactive-rest
_mikz 11y ago
Have you seen the actual code of the mutations? https://github.com/facebook/relay/blob/master/examples/todo/js/mutations/ChangeTodoStatusMutation.js https://github.com/facebook/relay/blob/master/examples/todo/... It is ... massive!
- joelgrus 11y ago
  Yeah, as someone who knows a fair amount of JS but almost nothing about React, that todomvc implementation does not particularly scream "this is the framework you want to learn".
- yazaddaruvala 11y ago
  One thing I think is a poor design choice on the part of the implementer of this example: 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.
  - underwater 11y ago
    Mutations are global, not view specific. They can be triggered by multiple views, and are smart enough to only refetch the data that is currently being shown. For Facebook we can write a single "like" mutation and share it between comments, posts, photos, etc.
- underwater 11y ago
  The API for mutations is one of the things we were least happy with, but we thought it was better to ship and iterate rather than get stuck on wanting to perfect everything out of the gate. Hopefully we can remove most of the boilerplate over time. 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.
polskibus 11y ago
Can someone explain to me how are they using all JS (node incl server-side rendering) stack in a company that is known for using PHP on the backend ? 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.
- petrbela 11y ago
  Their GraphQL server is written in PHP. They've made the reference implementation (graphql-js) in JS + the server in Express but they're not using that in production. For server side rendering of the React app, they use https://github.com/reactjs/react-php-v8js https://github.com/reactjs/react-php-v8js (well they probably use a slightly customized version but this is what they open sourced).
  - cpojer 11y ago
    We are not using php-v8js for server rendering at FB.
    - petrbela 11y ago
      I stand corrected. :)
- deleted 11y ago
  [deleted]
- cpojer 11y ago
  We are experimenting with it and I've built a service for JS at FB. I'm convinced that server rendering should be transparent to a product developer – ie no special work should be required and the server rendering infra should decide automatically whether it will render on the server or not. 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 :)
zkhalique 11y ago
Wow, looks like what we've been doing for the last 4 years is very similar to the design of Facebook's tools they've been open sourcing. That is some serious validation for our architecture! (For anyone who's interested here was our design: http://platform.qbix.com/guide/tools http://platform.qbix.com/guide/tools, http://platform.qbix.com/guide/messages http://platform.qbix.com/guide/messages)
- hokkos 11y ago
  It doesn't look like relay at all, could you clarify what design is the same ?
  - zkhalique 11y ago
    This stuff: 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 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. See http://platform.qbix.com/guide/messages http://platform.qbix.com/guide/messages
platz 11y ago
Seems like it has some similarites to OData. 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
jmcatani 11y ago
The major advantage of Relay/GraphQL seems to be if you have one monolithic data model for your entire codebase. You are in effect, binding your views directly to your backend. This is great if you are a company like Facebook with a single graph holding all data. 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.
- dbb01 11y ago
  This is actually incorrect. The Relay/GraphQL folks explicitly call out the concept of directly exposing your persistence structure via GraphQL as detrimental. Instead, you simply describe what your business models are with GraphQL (regardless of how they're stored), just as you would with a REST api. GraphQL acts as an abstraction layer on top of your persistence. The key difference with GraphQL vs a REST API is that you don't have to commit specific endpoints that return specific models, the clients can simply pick and choose (within the confines of what your GraphQL schema allows).
knite 11y ago
I've skimmed the Relay and GraphQL repos, but I can't for the life of me figure out which database backends are supported. Can I put this in front of Postgres? Redis? How do I stand this up in front of an existing DB?
- iamflimflam1 11y ago
  From what I understand you build that bit yourself https://www.reindex.io/blog/building-a-graphql-server-with-node-js-and-sql/ https://www.reindex.io/blog/building-a-graphql-server-with-n...
- tootie 11y ago
  As I understand it, this is still 100% client-side. GraphQL is basically a new schema language for defining a web service contract. You still need a complete server-side implementation to satisfy the schema. And unless you're doing it in node, there is probably no tooling in your language.
- tlrobinson 11y ago
  GraphQL is very new at this point, so there aren't many backends/databases that support it. If it catches on I imagine that will change very rapidly.
chadly 11y ago
How does this compare with Flux? Is it intended to be used with Flux or instead of Flux?
- underwater 11y ago
  It should be used instead of Flux. 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.
  - quicksnap 11y ago
    Is it not advisable to use Relay alongside Flux? I would think they could compliment each other nicely.
    - underwater 11y ago
      You can, and we do exactly that for some apps at Facebook. Ideally Relay could completely replace Flux. This is something we hope to build soon.
TeeWEE 11y ago
The idea of Relay is cool. And GraphQL is indeed a nice thing for mobile engineers and product developers. I think its a novel way to query data. 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.
timtadh 11y ago
I wish facebook had not used "GraphQL" as their name for their SOAP/REST/RPC replacement. When I hear GraphQL I think of a query language for graphs. Like in (for instance) http://dl.acm.org/citation.cfm?id=1368898 http://dl.acm.org/citation.cfm?id=1368898 . There has been a lot of cool research over the years on query languages for graphs. Facebook's "GraphQL" is totally nerfing Google's ability to find it.
- deleted 11y ago
  [deleted]
fiatjaf 11y ago
More undebuggable magic.
- fiatjaf 11y ago
  I had 12 upvotes here, and then returned to 1.
foxhedgehog 11y ago
Exciting. So does this do away with implementations of Flux (like the excellent Redux), or is there room for them to work in concert?
- deleted 11y ago
  [deleted]
leothekim 11y ago
This is the best commit message: ༼ つ ◕_◕ ༽つ Give RELAY https://github.com/facebook/relay/commit/2a86be3e71cdc6511fa994e3de539f72070da1b4 https://github.com/facebook/relay/commit/2a86be3e71cdc6511fa...
darkmarmot 11y ago
Aspects of React, Relay and Flux make me feel like my company's js framework could end up like Leibniz once we release it this fall...
- iLoch 11y ago
  A word of caution: you're probably right. React, Angular, Backbone cover most use cases and are proven in production, well known, and well understood. Unless you're a big company with hard problems, why should anyone pay attention? Not to rain on your parade, I've had the inclination to build my own libraries in the past as well but I always remember why it's not a good plan. 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.
nwmcsween 11y ago
So graphql is basically a query language and optimizer? Why not have a relational algebra library, query (sql, whatever) generator and optimizer as separate things?
gamekathu 11y ago
another awesome gift from facebook, thanks a lot devs! but i am still eagerly waiting for React native for Android.. any updates on its development?
lewisl9029 11y ago
Any idea why they decided to use string-based queries for GraphQL? 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. [1] https://www.youtube.com/watch?v=ByNs9TG30E8 https://www.youtube.com/watch?v=ByNs9TG30E8
- tracker1 11y ago
  You can always use JS/ES6 string templates (using Babel or Traceur).
pathsjs 11y ago
Can anyone explain what this is all about? I followed the tutorial, but still cannot understand what are the ideas behind Relay/GraphQL. There must be some principles why the application is structured that way, but without seeing them, it looks like layers of indirection for the sake of complication. 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? :-)
- alexobenauer 11y ago
  Nothing explains the motivations for Relay/GraphQL better than their introduction of it earlier this year, I'd recommend watching the video: http://facebook.github.io/react/blog/2015/02/20/introducing-relay-and-graphql.html http://facebook.github.io/react/blog/2015/02/20/introducing-...
  - pathsjs 11y ago
    Is there anything in text format? I really cannot follow the whole video right now. I tried to follow the slides, but they do not make much sense alone. 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?

474 points by cpojer 11y ago

The release commit is really the best: https://www.dropbox.com/s/9gx377scddhxo95/Screenshot%202015-08-11%2012.35.52.png?dl=0 https://www.dropbox.com/s/9gx377scddhxo95/Screenshot%202015-... All I can say now is: ༼ つ ◕◡◕ ༽つ Got RELAY

falcor84 11y ago
Just putting a live link to that commit here: https://github.com/facebook/relay/tree/2a86be3e71cdc6511fa994e3de539f72070da1b4 https://github.com/facebook/relay/tree/2a86be3e71cdc6511fa99...

stevebmark 11y ago

I'm really excited about this! While working on an "isomorphic" app, data fetching gets incredibly complicated. There are many edge cases. For example, when rendering on the server, you have to block all renders until all data fetching is complete. But on the client, you can show the view with a "loading" indicator, as in not block. But you only need to fetch data for that route on the client if it hasn't been fetched on the server...the rabbit hole is full of wheels you don't want to reinvent. I'm hoping Relay solves the data fetch problem in a way that makes isomorphic applications much cleaner.

dsp1234 11y ago
you have to block all renders until all data fetching is complete. Not if you use a server side templating engine that supports async rendering like MarkoJs [0][1]. [0] - https://marko-progressive-rendering.herokuapp.com/ https://marko-progressive-rendering.herokuapp.com/ [1] - https://github.com/marko-js/marko https://github.com/marko-js/marko
- stevebmark 11y ago
  I'm spoiled by the niceness of JSX. It's a very clean and expressive and easy to read language, because it's only what I already know, Javascript and HTML. There are no APIs to learn (except for some minor cases, like inline comments). This template language looks like it would only have downsides compared to JSX. It's a new syntax to learn, and less expressive. This templating language even adds HTML-like attributes! What a mess. Also I don't think the templating language has anything to do with the nature of blocking vs non-blocking data fetching.
  - marcusarmstrong 11y ago
    it's only what I already know, Javascript and HTML But it's not. "className", much?
    - Nogs 11y ago
      http://www.w3schools.com/jsref/prop_html_classname.asp http://www.w3schools.com/jsref/prop_html_classname.asp
      - marcusarmstrong 11y ago
        Sure. But that's different than <div className="blah">.
        smhg 11y ago
        Not much. These are actually the Web API attribute names you should use when accessing these attributes from a non-HTML language (e.g. JavaScript). The React folks didn't make them up.
      - smhg 11y ago
        w3schools might have gotten a bit better lately, but please use MDN as a reference: https://developer.mozilla.org/en-US/docs/Web/API/Element/className https://developer.mozilla.org/en-US/docs/Web/API/Element/cla... They offer so much more context.
sergiotapia 11y ago
Meteor already does this. In your template (Blaze) you can wait for your subscriptions to be ready and in the meantime render a loading icon or something else. Check it out!
- alanning 11y ago
  In this case, I think the more accurate example would be Meteor + React [1]. You can still show the "wait for data to be ready" state as you described. (For those interested, follow the linked tutorial.) 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/ http://react-in-meteor.readthedocs.org/en/latest/ 2. https://github.com/kadirahq/flow-router/tree/ssr https://github.com/kadirahq/flow-router/tree/ssr 3. https://kadira.io/blog/meteor/meteor-ssr-support-using-flow-router-and-react https://kadira.io/blog/meteor/meteor-ssr-support-using-flow-...

aikah 11y ago

> While working on an "isomorphic" app 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-javascript 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.

stevebmark 11y ago
Never.
aaron-lebo 11y ago
Words take on new, unintended, and incorrect meanings all the time. It's how language works. 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.
- aikah 11y ago
  > Words take on new, unintended, and incorrect meanings all the time. It's how language works. 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.
  - lol_haha 11y ago
    https://en.wikipedia.org/wiki/History_of_the_English_language https://en.wikipedia.org/wiki/History_of_the_English_languag... might be a good starting point.
  - mindcrime 11y ago
    We are developers not salesmen 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.

AlwaysBCoding 11y ago

I'm totally cool with Facebook mining my data if their open source keeps up this pace. GraphQL + Relay are total game changers for structuring web + mobile applications. Code bases get cleaner and more reliable. Less data gets sent over the wire. Other cool libraries are going to be built on top of Relay (I'm pretty excited to see what can be done now with ClojureScript components in .cljc files). 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.

graffitici 11y ago
Can you expand on what you mean by "what can be done with ClojureScript components in .cljc files"? Is Facebook also working with ClojureScript?
- petrbela 11y ago
  ClojureScript community is pretty close to React (see e.g. Om), and since React 0.13 supports plain classes, they can be written in CS. So FB itself might not be doing anything with CS but enables the CS community to work in the same ecosystem.
- AlwaysBCoding 11y ago
  Well the whole idea of Relay is to couple together the rendering logic of a UI component with the data fetching requirement of the component. So if you change the rendering logic of the component, the data that is fetched from the server will also change with it and you'll never be over/under fetching data. 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.

picardo 11y ago

This is very exciting. Facebook's commitment to open source never ceases to impress me. They could keep this technology to themselves and have light years or we'd only read it in academic papers, like Google has done with its core technologies, and someone else would have to reverse engineer them. But Facebook gives the entire code base. No other large company I know of has such a strong commitment to open source.

ThundaUp 11y ago
Netflix has a pretty awesome open source library, they are worth checking out as well. https://netflix.github.io/ https://netflix.github.io/
- curun1r 11y ago
  It's funny you should mention Netflix. They demoed something called Falkor two years ago that is/was extremely similar to Relay/GraphQL. It's unfortunate that it's made so little progress in the past two years, but it wouldn't surprise me of the talks on Falkor had influenced or inspired Facebook's implementation. For those that want links: https://twitter.com/falcorjs https://twitter.com/falcorjs http://moduscreate.com/falcor-mvc-for-an-asynchronous-world http://moduscreate.com/falcor-mvc-for-an-asynchronous-world https://www.youtube.com/watch?v=z8UgDZ4rXBU https://www.youtube.com/watch?v=z8UgDZ4rXBU
  - spicyj 11y ago
    > two years ago 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.
    - curun1r 11y ago
      You're mistaken. My first exposure to it was a talk at QCon in Nov 2013. It wasn't posted publicly online until Feb 2014, but here's the link: http://www.infoq.com/presentations/netflix-reactive-rest http://www.infoq.com/presentations/netflix-reactive-rest

_mikz 11y ago

Have you seen the actual code of the mutations? https://github.com/facebook/relay/blob/master/examples/todo/js/mutations/ChangeTodoStatusMutation.js https://github.com/facebook/relay/blob/master/examples/todo/... It is ... massive!

joelgrus 11y ago
Yeah, as someone who knows a fair amount of JS but almost nothing about React, that todomvc implementation does not particularly scream "this is the framework you want to learn".
yazaddaruvala 11y ago
One thing I think is a poor design choice on the part of the implementer of this example: 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.
- underwater 11y ago
  Mutations are global, not view specific. They can be triggered by multiple views, and are smart enough to only refetch the data that is currently being shown. For Facebook we can write a single "like" mutation and share it between comments, posts, photos, etc.
underwater 11y ago
The API for mutations is one of the things we were least happy with, but we thought it was better to ship and iterate rather than get stuck on wanting to perfect everything out of the gate. Hopefully we can remove most of the boilerplate over time. 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.

polskibus 11y ago

Can someone explain to me how are they using all JS (node incl server-side rendering) stack in a company that is known for using PHP on the backend ? 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.

petrbela 11y ago
Their GraphQL server is written in PHP. They've made the reference implementation (graphql-js) in JS + the server in Express but they're not using that in production. For server side rendering of the React app, they use https://github.com/reactjs/react-php-v8js https://github.com/reactjs/react-php-v8js (well they probably use a slightly customized version but this is what they open sourced).
- cpojer 11y ago
  We are not using php-v8js for server rendering at FB.
  - petrbela 11y ago
    I stand corrected. :)
deleted 11y ago
[deleted]
cpojer 11y ago
We are experimenting with it and I've built a service for JS at FB. I'm convinced that server rendering should be transparent to a product developer – ie no special work should be required and the server rendering infra should decide automatically whether it will render on the server or not. 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 :)

zkhalique 11y ago

Wow, looks like what we've been doing for the last 4 years is very similar to the design of Facebook's tools they've been open sourcing. That is some serious validation for our architecture! (For anyone who's interested here was our design: http://platform.qbix.com/guide/tools http://platform.qbix.com/guide/tools, http://platform.qbix.com/guide/messages http://platform.qbix.com/guide/messages)

hokkos 11y ago
It doesn't look like relay at all, could you clarify what design is the same ?
- zkhalique 11y ago
  This stuff: 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 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. See http://platform.qbix.com/guide/messages http://platform.qbix.com/guide/messages

platz 11y ago

Seems like it has some similarites to OData. 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

jmcatani 11y ago

The major advantage of Relay/GraphQL seems to be if you have one monolithic data model for your entire codebase. You are in effect, binding your views directly to your backend. This is great if you are a company like Facebook with a single graph holding all data. 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.

dbb01 11y ago
This is actually incorrect. The Relay/GraphQL folks explicitly call out the concept of directly exposing your persistence structure via GraphQL as detrimental. Instead, you simply describe what your business models are with GraphQL (regardless of how they're stored), just as you would with a REST api. GraphQL acts as an abstraction layer on top of your persistence. The key difference with GraphQL vs a REST API is that you don't have to commit specific endpoints that return specific models, the clients can simply pick and choose (within the confines of what your GraphQL schema allows).

knite 11y ago

I've skimmed the Relay and GraphQL repos, but I can't for the life of me figure out which database backends are supported. Can I put this in front of Postgres? Redis? How do I stand this up in front of an existing DB?

iamflimflam1 11y ago
From what I understand you build that bit yourself https://www.reindex.io/blog/building-a-graphql-server-with-node-js-and-sql/ https://www.reindex.io/blog/building-a-graphql-server-with-n...
tootie 11y ago
As I understand it, this is still 100% client-side. GraphQL is basically a new schema language for defining a web service contract. You still need a complete server-side implementation to satisfy the schema. And unless you're doing it in node, there is probably no tooling in your language.
tlrobinson 11y ago
GraphQL is very new at this point, so there aren't many backends/databases that support it. If it catches on I imagine that will change very rapidly.

chadly 11y ago

How does this compare with Flux? Is it intended to be used with Flux or instead of Flux?

underwater 11y ago
It should be used instead of Flux. 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.
- quicksnap 11y ago
  Is it not advisable to use Relay alongside Flux? I would think they could compliment each other nicely.
  - underwater 11y ago
    You can, and we do exactly that for some apps at Facebook. Ideally Relay could completely replace Flux. This is something we hope to build soon.

TeeWEE 11y ago

The idea of Relay is cool. And GraphQL is indeed a nice thing for mobile engineers and product developers. I think its a novel way to query data. 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.

timtadh 11y ago

I wish facebook had not used "GraphQL" as their name for their SOAP/REST/RPC replacement. When I hear GraphQL I think of a query language for graphs. Like in (for instance) http://dl.acm.org/citation.cfm?id=1368898 http://dl.acm.org/citation.cfm?id=1368898 . There has been a lot of cool research over the years on query languages for graphs. Facebook's "GraphQL" is totally nerfing Google's ability to find it.

deleted 11y ago
[deleted]

fiatjaf 11y ago

More undebuggable magic.

fiatjaf 11y ago
I had 12 upvotes here, and then returned to 1.

foxhedgehog 11y ago

Exciting. So does this do away with implementations of Flux (like the excellent Redux), or is there room for them to work in concert?

deleted 11y ago
[deleted]

leothekim 11y ago

This is the best commit message: ༼ つ ◕_◕ ༽つ Give RELAY https://github.com/facebook/relay/commit/2a86be3e71cdc6511fa994e3de539f72070da1b4 https://github.com/facebook/relay/commit/2a86be3e71cdc6511fa...

darkmarmot 11y ago

Aspects of React, Relay and Flux make me feel like my company's js framework could end up like Leibniz once we release it this fall...

iLoch 11y ago
A word of caution: you're probably right. React, Angular, Backbone cover most use cases and are proven in production, well known, and well understood. Unless you're a big company with hard problems, why should anyone pay attention? Not to rain on your parade, I've had the inclination to build my own libraries in the past as well but I always remember why it's not a good plan. 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.

nwmcsween 11y ago

So graphql is basically a query language and optimizer? Why not have a relational algebra library, query (sql, whatever) generator and optimizer as separate things?

gamekathu 11y ago

another awesome gift from facebook, thanks a lot devs! but i am still eagerly waiting for React native for Android.. any updates on its development?

lewisl9029 11y ago

Any idea why they decided to use string-based queries for GraphQL? 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. [1] https://www.youtube.com/watch?v=ByNs9TG30E8 https://www.youtube.com/watch?v=ByNs9TG30E8

tracker1 11y ago
You can always use JS/ES6 string templates (using Babel or Traceur).

pathsjs 11y ago

Can anyone explain what this is all about? I followed the tutorial, but still cannot understand what are the ideas behind Relay/GraphQL. There must be some principles why the application is structured that way, but without seeing them, it looks like layers of indirection for the sake of complication. 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? :-)

alexobenauer 11y ago
Nothing explains the motivations for Relay/GraphQL better than their introduction of it earlier this year, I'd recommend watching the video: http://facebook.github.io/react/blog/2015/02/20/introducing-relay-and-graphql.html http://facebook.github.io/react/blog/2015/02/20/introducing-...
- pathsjs 11y ago
  Is there anything in text format? I really cannot follow the whole video right now. I tried to follow the slides, but they do not make much sense alone. 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?