Hacker News new | past | comments | ask | show | jobs | submit login

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.



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.


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.


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.


this is so true.


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.


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


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.


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


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?


Great to hear that :) We plan on writing a series of blog posts to cover EdgeDB and some of the concepts behind it.


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?


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.


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.


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.


As long as it doesn't result in a monolithic "framework" that is difficult to replace or modularize.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: