This article is by Armin Ronacher, the author of Flask. I use Flask for most of my projects because it's decoupled from the ORM and provides a clean way for you to use whatever database tool is right for the job.
But lately I have moved away from using the relational database as the primary datastore. When I do need a relational database, it's simple to use SQLAlchemy in Flask.
But I have been finding graph databases as a more elegant alternative to relational databases because you don't have to mess with tables or joins -- everything is explicitly joined.
Neo4j is one of the leading open-source graph databases, and it's pretty sweet -- it can store 32 billion nodes while doing 2 million traversals per second -- and you can use Gremlin with it (Gremlin is a graph query language, like SQL for graphs).
The graph-database world is starting to emerge, but most graph databases are Java based so non-JVM bindings are not always available.
However, there is a project called TinkerPop (http://www.tinkerpop.com) that has made most of the open-source software stack for graph DBs. TinkerPop is the project that developed Gremlin and Blueprints, and it released a REST service called Rexster that is tied to Blueprints so it lets you connect to any Blueprints-enabled graph database, including Neo4j, OrientDB, Dex, OpenRDF, and an InfiniteGraph implementation is being released next month.
Because the graph-DB world lacked Python support, I decided to write a Python persistence framework that connects to Rexster so you can now use any of those graph DBs from Python, and binary bindings are in the works. The framework is called Bulbflow, and you can find out more about it out at http://bulbflow.com/overview.
In a few weeks I'm going to release Flask-based libraries that do authentication and authorization in a graph-DB way.
You've been posting quite a bit about graph DBs lately including one the other day which stated that "the relational DB is dying as the primary datastore" as well as "Graphs are a much more elegant way of storing relational data". (source: http://news.ycombinator.com/item?id=2778945).
I have to disagree with you here. Graph DBs are a much more elegant way to store graph data, i.e. social media data, some forms of scientific data. But for the vast majority of relational database usage, i.e. finance, accounting, retail, medical records, human resources, academia, reservation databases, etc. the truly vast amount of databases we interact with indirectly all day long, these systems are firmly in the relational camp and that is not changing anytime soon. SQLAlchemy would very much like Python to be prevalent throughout all these industries, and is not just about social media applications.
Because Flask is decoupled, it let's you use whatever tool is right for the job. If you need to store financial data, it's easy to use SQLAlchemy, but graph databases are much better fit for work working with stuff like the modern-day social graph.
And don't get me wrong, I like SQLAlchemy -- I have used it for years and continue to use it -- thank you for all the work you've put into it.
Look at the trend for Britney Spears compared to PostgreSQL (http://www.google.com/trends?q=britney+spears%2C+postgresql&...). I'm not sure what to make of it because Britney Spears and mongodb do not offer a tenth of the features of postgresql, yet they are clearly more popular.
In computer science, I believe everything can be seen as a graph so of course, graph databases are a great fit for every problem. Object databases were also a great fit for objects. But where are object databases now compared to relational databases?
It's great to have so many options now and it's great to see nosql databases giving ideas to sql databases (http://momjian.us/main/blogs/pgblog/2010.html#April_10_2010_...). Although relational databases might be less elegant for immediate programming problems, they are far more flexible when new needs emerge and their ACID properties have a far better track record than most (if not all given their age) nosql databases.
> Because Flask is decoupled, it let's you use whatever tool is right for the job.
(Derail alert)
How is it any more difficult to use a graph database in Django? (Hint: if you say "but then you can't use X" my next question is "are you implying Flask includes X and you can automagically use X with a graph database?")
You absolutely can use a graph DB in Django. But if you're not using a relational DB as your primary datastore (for stuff like authentication and authorization) and not using the ORM, how much of Django would you really use?
Django was built around an ORM. Now you have more database options that have less of an impedance mismatch, but because Django is so ORM-centric, forgoing the RDBMS in favor of another option means you now have a framework mismatch.
Starting with Flask, which was designed to be decoupled, simplifies things.
The URL mapper, the view abstraction, the middleware, the debugging tools, the generic views concept, the httprequest and httpresponse classes, the templating system, the caching framework, the syndication library and a bunch of the third party ecosystem tools.
Becaus I'm more familiar and have experienced in using it. Because I decided to use Django for the other part of my big web application. Because I want to learn more and get better with my tool as opposed to learn the Python web app framework of the week.
You're right -- I was just using Mongo as an example to show that people are moving away from the relational database as the primary datastore, esp for Web stuff.
You've been posting quite a bit about graph DBs lately
I have been a strong advocate for SQLAlchemy too (http://news.ycombinator.com/item?id=2456994). It's just that I discovered the power of graph DBs a few months ago and have grown quite fond of them.
thanks for that. also, it's worth noting that the licence for ne04j changed recently - the community edition is now GPL rather than AGPL, so it can be used to bootstrap web services for free (if you ever do need to upgrade to the paid-for version then you are hopefully at a scale where you can start charging customers and paying for software).
[i'm not connected to neo4j in any way; i was interested in using it a while back (for what might have become a commercial project), but was discouraged by the agpl licence, so thought i'd share the good news]
Yes. The Neo4j community edition is always free, and as long as your code is open source, the enterprise edition is also free even for commercial use (http://neo4j.org/licensing-guide/).
But lately I have moved away from using the relational database as the primary datastore. When I do need a relational database, it's simple to use SQLAlchemy in Flask.
But I have been finding graph databases as a more elegant alternative to relational databases because you don't have to mess with tables or joins -- everything is explicitly joined.
Neo4j is one of the leading open-source graph databases, and it's pretty sweet -- it can store 32 billion nodes while doing 2 million traversals per second -- and you can use Gremlin with it (Gremlin is a graph query language, like SQL for graphs).
The graph-database world is starting to emerge, but most graph databases are Java based so non-JVM bindings are not always available.
However, there is a project called TinkerPop (http://www.tinkerpop.com) that has made most of the open-source software stack for graph DBs. TinkerPop is the project that developed Gremlin and Blueprints, and it released a REST service called Rexster that is tied to Blueprints so it lets you connect to any Blueprints-enabled graph database, including Neo4j, OrientDB, Dex, OpenRDF, and an InfiniteGraph implementation is being released next month.
Because the graph-DB world lacked Python support, I decided to write a Python persistence framework that connects to Rexster so you can now use any of those graph DBs from Python, and binary bindings are in the works. The framework is called Bulbflow, and you can find out more about it out at http://bulbflow.com/overview.
In a few weeks I'm going to release Flask-based libraries that do authentication and authorization in a graph-DB way.