Relay: Declarative data for React applications
code.facebook.com
code.facebook.com
The reason: SQL, even PostgreSQL with userdefined functions, is not strict enough for me. As soon as a consistency rule involves multiple tables, things. There are some nice SQL tricks with duplicating columns across those tables, whose consistency is ensured by putting them as additional columns into foreign keys. But for my taste this is too much trickery, and this approach has its limits as well.
I hope that one day the Graph databases will be combined with strict schemas that go far beyond XML schema, JSON schema and SQL database constraints. Also I hope that expressing those constraints should be easier, not harder, to read when applied to a graph database.
The graph database model is driven largely by a desire for better navigational convenience at the expense of weaker schemas compared to RDBMS models. So, while you can wish for anything, I don't see that that's likely to happen. RDBMSs start ahead of graph databases when it comes to stronger schemas, and there's no reason that any stronger schema techniques would be more applicable to graph databases than to RDBMSs.
I agree that today's graph databases are meant to be used for weaker schemas, I believe that they are conceptually a better fit for strict schemas than relational databases are.
But probably we need a third term for those ultra-strict databases. From the "look and feel", this new type would almost certainly look more similar to a graph db than a relational db.
You may be interested in (soon to be released) EdgeDB: http://edgedb.com/
(Disclaimer: I'm one of the devs behind it).
Alas, there is no RSS/Atom feed. If that site had one, I would have thrown it into my RSS reader. (I hesitate to throw my email address into such sites, sorry.)
BTW, will there be an Open Source version of the DB?
As for emails - we won't disclose them to anyone, or fire emails more often than 1 in 3-4 weeks.
I mean, if facebook are using it heavily, then one can presume it works nicely at scale, but they don't seem to be doing amazingly well at the "make the easy things easy" side of things (yet).
class Score extends React.Component {
render() {
var {initials, score} = this.props.score;
return (
<li key={initials}>
<strong>{initials}</strong> {score}
</li>
);
}
}
Score = Relay.createContainer(Score, {
fragments: {
score: () => Relay.QL`
fragment on Score {
initials,
score,
}
`,
},
});
This Facebook people know how to make me uncomfortable. But I guess I could get used, the same way I got used to JSX...
A class in javascript is just a variable, after all.
I think, personally, I'd've called the initial class ScoreGuts or something, or gone with a different syntax that returned the class as a value, but ... eh. It's really not that big a deal.
> I think, personally, I'd've called the initial class ScoreGuts or something
Well, maybe the point is that the original class becomes "useless" once it has been "decorated"; so it doesn't make sense that it has its own name. But it's is also true that, once you get used to program using FP style, mutating variables like this feels "weird".
Score = do_the_decoration((function () {
class Score ... {
...
}
return Score;
)());
Lol!
Consider it like:
var a = 1;
a = func(a);
var Score = (props) => (
<li key={props.score.initials}>
<strong>{props.score.initials}</strong> {props.score.score}
</li>
);
Score = Relay.createContainer(Score, {
fragments: {
score: () => Relay.QL`
fragment on Score {
initials,
score,
}
`,
},
});I was confused because I didn't realize that, actually, a class in ES6 is just a variable. Also, I am not used to the decorator pattern. Now it makes sense.
TypeError: Class constructors cannot be invoked without 'new'That's definitely much nicer than the old way.
A nice talk / use case given here:
Now Relay and GraphQL have been officially released and moved out of tech preview.
The speed of iteration is fantastic since you don't need to constantly create new endpoints/fiddle with the data your server provides every time you want to pull in a little extra data. You also get pagination basically for free.
I can recommend sangria for the graphql server - a strongly typed language gives you better confidence, and it's built on akka-http so it'll be performant too.
For browser compatibility reasons, I do see the necessity for Relay (HTTP being much more widely supported than WebSockets) but Relay is definitely not the end-game.