Live data from Hacker News

Build your next app with a graph database

dgraph.io

1–10 of 58 posts

Re: Build your next app with a graph database

#5
I built an app with Neo4j once. It was a Rails app, built it from scratch in Neo4j.rb. I was hired by business where the owner hadn't coded any apps in 15 years and was obsessed with the theory of the graph database and how it was so much "easier" than using SQL.

Suddenly, every useful gem that allows you to throw together an app in 5 minutes had to be rewritten from the ground up. Things like authentication, pagination, etc. which could be done in 10 minutes in a standard Rails app took days.

The worst part is that I was not permitted to contribute these customs gems back to Open Source. He was a very selfish person who used almost exclusively proprietary software and thought that any of the long hours we spent to rebuild all of these basic puzzle pieces to work with Neo4J would give other people a leg up or advantage - as if competitors out there would decide to build a direct competitor with our identical tech stack and we wanted to slow them down as much as possible... sorry boss, but if they wanted to build a competitor prototype they would just build it with an SQL relational database and have the entire app done in 2 weeks.

About 3 months into the project I mentioned to someone at a technology meetup that I was building in app in Neo4j.rb and he laughed at me. I was drinking the graph koolaid still at the time and tried telling him about the advantages. He told me that as soon as the app was deployed I would see how much extra work I would have in-store for me. To be fair, he was right. Migrations just didn't work the same. Eventually I was discharged from the company because I did not agree with the management's unethical business practices and continue doing shady things and agree with their moral jusitifcations for crimes so the app never actually saw the light of day.

I am sure there are many production apps succeeding with Neo4j, but in the end I just saw a project whose scope was 10x what it should have been. If you have a "slow" app that launches 3 months earlier than your competitor, you still win.

Re: Build your next app with a graph database

#6
It's a shame that almost no one knows or uses Versant OODBMS (object-oriented database management system).

As the name suggest it's object oriented and queries return graphs of objects.

It's heavily multi-threaded and has been around since 1989 (iirc).

The only big downside (besides being proprietary) is that it's almost impossible to scale out (horizontally). But it scales enormously well vertically (throw resources at it and it will happily use it in a very efficient manner).

Re: Build your next app with a graph database

#8
post #5

I built an app with Neo4j once. It was a Rails app, built it from scratch in Neo4j.rb. I was hired by business where the owner hadn't coded any apps in 15 years and was obsessed with the theory of the graph database and how it was so much "easier" than using SQL. Suddenly, every useful gem that allows you to throw together an app in 5 minutes had to be rewritten from the ground up. Things like authentication, paginat…

I also once got stuck under an org with leadership that’d fallen for N4J’s marketing. It was a bad fit for their needs by most any metric and leading to tons of stability problems, bugs, and development slowness. Hell one application they were developing on it would have been (much) better off with SQLite. Seriously. It was like early Mongodb hype all over again.

Re: Build your next app with a graph database

#10
I have never used a graph database but I can say there is one truth in the article: I find I have to stop and structure my app around the tables I need, and have had to stop and reorganize my code and data to fit a proper table structure when I realize my existing table structure doesn't make sense or hits the database too hard.

I have no idea if graph databases are the answer to that problem, but I do get tired of building code to work around my database and it's oddities rather than my data just fitting nicely into the code.

The number of migrations I've built just to change something because the database needed it built differently rather than my application needing it is silly.

Post reply on HN