HN Explorer

46 comments

[ 3.0 ms ] story [ 98.8 ms ] thread
ZitchDog
Between relay and react-native, we have the potential for a game-change in application architecture. A single repository could easily host frontends for each application target, (iOS, Android, web) along with a backend written in Relay/GraphQL. What's more, static analysis using flow/TypeScript could provide type checking across all applications, all the way back to the storage backend. Exciting stuff.
chairleader
I see a lot of promise here as well. I'm not sure if the world is ready to express everything in terms of graphs, though.
vog
I recently noticed that I want something like a graph database for an application that screams for an SQL database, a strict schema and strict constraints.

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.

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

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.

vog
Good points, but note that I came from the other side: I drafted a concept of how to formulate the strictest schemas that I would like to apply in the application. Then I realized that the underlying model resembles much more a graph model than a relational model.

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.

idibidiart
I thought the purpose of Relay is to get you to use a graph db. I think of GraphQL as a layer that sits between the REST API and web application, allowing you to specify custom queries that interact with the REST API behind the scene, so your REST layer can be application agnostic and you won't have to hardcode any application specific transformations between your REST API and your web or mobile or xbox etc app.
RedCrowbar
> I recently noticed that I want something like a graph database for an application that screams for an SQL database, a strict schema and strict constraints.

You may be interested in (soon to be released) EdgeDB: http://edgedb.com/

(Disclaimer: I'm one of the devs behind it).

robertfw
This looks excellent! Signed up for the newsletter. Can't wait to hear more. Do you have any other available info beyond what is on the site?
1st1
Great to hear that :) We plan on writing a series of blog posts to cover EdgeDB and some of the concepts behind it.
vog
Looks great!

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?

1st1
Yes, it will be open source.

As for emails - we won't disclose them to anyone, or fire emails more often than 1 in 3-4 weeks.

manx
Recently I'm experimenting a lot with Strict graph database schemas. This resulted in this library: https://github.com/renesca/renesca-magic , supporting multiple inheritance, hyperrelations and some more features.
dustingetz
All the business web apps I've worked on that use relational databases with an ORM layer, are already modeling the world as a half-baked graph. I'm reminded of https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule.
girvo
Recently I forced my coworker to use a real graph data structure in a LoB app. Nearly everything I've worked on ends up being an ad-hoc graph eventually, and as they say using the right data structures is half the battle.
amelius
As long as it doesn't result in a monolithic "framework" that is difficult to replace or modularize.
misiti3780
I havnt really spent too much time looking at Relay, so forgive me if this is a dumb question, but if you want to use the Relay paradigm do you not have to change your backend-apis to return GraphQL formatted JSON ?
hueyp
Yes, but GraphQL is just a thin layer so you can call your existing API's from GraphQL. For example you could start with GraphQL calling an existing HTTP service and go from there.

A nice talk / use case given here:

https://www.youtube.com/watch?v=S0s935RKKB4

graffitici
But Relay was already announced a few weeks ago, right? What's new with this blog post now,?
ville
The release few weeks ago was "Technical Preview".

Now Relay and GraphQL have been officially released and moved out of tech preview.

mst
The sheer amount of code required here just to get the trivial example set up is ... a little daunting.

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

andreamazz
Yeah, I wanted to try Relay for a small project a month ago, but getting started seems really time consuming, and the documentation was pretty poor, with just a contrived sample. The architecture seems great, I hope they improve the doc now that it's out of the tech preview.
6t6t6
This is unsettling:

  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,
        }
      `,
    },
  });
Soo, if I understood well, first they create a class and then they create a global variable reusing the same name of the class, in order to create and object that expands the class?

This Facebook people know how to make me uncomfortable. But I guess I could get used, the same way I got used to JSX...

anarchy8
If I recall correctly, this is simply a decorator. Using ES7, you could write the createContainer call using the new decorator syntax and avoid this uncomfortableness.
mst
They create a class, then they wrap the class in a class.

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.

6t6t6
Now I understand. Thank you!

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

mst
Yeah, that would seem like the motivation, but it feels a bit weird to me too. It occurs to me that you could probably do something like

    Score = do_the_decoration((function () {
      class Score ... {
        ...
      }
      return Score;
    )());
but that's not exactly 100% better, just weird to a different subset of people :)
6t6t6
> but that's not exactly 100% better, just weird to a different subset of people

Lol!

masterj
In the example you used you're re-defining the class by wrapping it, not creating a global variable...

Consider it like:

  var a = 1;
  a = func(a);
Does it seem cleaner if you use the stateless functions from React 0.14? http://facebook.github.io/react/blog/2015/09/10/react-v0.14-...

  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,
        }
      `,
    },
  });
6t6t6
Thank you very much for the explanation!

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.

azernik
It's even worse - classes in ES6 are just functions (their constructors); 'obj = new Class()' is just sugar for 'obj = {}; Class.bind(obj)()'. So if you leave off the "new", you'll end up clobbering whatever 'this' defaults to, which is usually the global window object.
moretti
Actually, if you leave off the "new" you get a TypeError:

    TypeError: Class constructors cannot be invoked without 'new'
azernik
Depends on your browser and/or transpiler :-)

That's definitely much nicer than the old way.

xiaoma
I've really been starting to love fb in this past year in a way I never thought I'd love any big company.
ergo14
Still, you should read additional patents clause in their projects - not only license terms.
estefan
I'm just finishing my first relay/react app. This stack is amazing. It will blow REST away. This time next year I'd be surprised if people are still creating REST servers for greenfield projects. Seriously, it's a game changer.

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.

jondubois
I feel that client-side pub/sub over WebSockets is a more natural solution to the problem of binding front-end views to server-side data.

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.

PudgePacket
Is it possible to use relay without graphql or are they baked together?
rafalsobota
Relay is much more than GraphQL and GraphQL will be optional in the future.