neo4js, node.js & me

271 views
Skip to first unread message

Adam Crabtree

unread,
May 14, 2012, 6:47:23 PM5/14/12
to ne...@googlegroups.com
Howdy,

I'm new to neo4j coming from JavaScript/node.js (little to no Java), and I had a couple questions. First though, I just want to tell you guys how cool I think neo4j is and excited I am to use it, but I have some questions about the current state of neo4j support in JavaScript and node.js.

It seems neo4js is the officially supported JavaScript library, made node.js compatible. It seems though that there hasn't been any significant contributions for close to 4 months. Additionally, the documentation consists entirely of a single example. So... I'm curious:

Is anyone actively developing on neo4js?
Is it feature complete or is there another reason for the lack of contributions?
Which leads to, is anyone using it in production?
Is neo4j/neo4js still too early to be used in production?

Also, the github repo for neo4js is not node.js compatible, so I'm assuming there is a build step somewhere to make it so? How is the current source intended to be used / built?

Personally, I thought I'd mention this as well, and this is entirely subjective, but I'm not a fan of promises. I saw node-neo4j which doesn't use promises, but it uses streamline & coffee internally, which *sigh* is equally awkward. I find it personally frustrating that there is no vanilla callback-based implementation that doesn't use coffeescript, streamline or promises. (Yes I know coffeescript compiles, but it compiles to incredibly ugly hardly readable fully functional code) This is especially frustrating since the lack of documentation requires one to read the source, which leads to the following issues:

1. The neo4js source in github is not node.js compatible, so following how it's intended to be used is awkward.
2. Inspection at runtime to determine its use is equally awkward due to the promises abstraction layer.
3. node-neo4j source requires me to learn coffeescript and streamline or read ugly compiled code. 

Long story short, these are barriers-to-entry for anyone looking to use neo4j in node.js. Not insurmountable by any means, but I thought I'd make you guys aware of them if in case you weren't.


So, are there any good resources, blog posts, documentation, examples, etc... that anyone here can provide for getting started with neo4j in node.js? I'm sure they'll be handy for anyone else stumbling across this as well. =)

It seems that the best route may just be the REST API and cypher??  Is this the default non-Java / non-native approach? How does the REST API performance compare with 

Cheers & Thanks,
Adam Crabtree

--
Better a little with righteousness
       than much gain with injustice.
Proverbs 16:8

Peter Neubauer

unread,
May 15, 2012, 3:22:58 AM5/15/12
to ne...@googlegroups.com
Adam,
we are using Neo4js in the Neo4j Webadmin, so from that perspective it
is actively maintained. However, the Node.js focus is probably bigger
in https://github.com/thingdom/node-neo4j, and contributions are very
welcome I think. Thomas Baum has been introducing the future support
in order to demo https://github.com/tbaum/heroku-node-neo4js and
node.js support on Heroku.

What do you think would be the least-cost path to get a nice Neo4j -
REST - Cypher javascript client for Node.js out?

Cheers,

/peter neubauer

G:  neubauer.peter
S:  peter.neubauer
P:  +46 704 106975
L:   http://www.linkedin.com/in/neubauer
T:   @peterneubauer

If you can write, you can code - @coderdojomalmo
If you can sketch, you can use a graph database - @neo4j

Aseem Kishore

unread,
May 17, 2012, 5:15:04 PM5/17/12
to ne...@googlegroups.com
Hey Adam,

I'm the (co-)author and maintainer of node-neo4j. We built it for The Thingdom <http://www.thethingdom.com/> and have been using it (and Neo4j) in production for over a year now.

We definitely need better documentation -- including an API reference, so you shouldn't have to read the code to discover its API.


I understand that not everyone uses or likes CoffeeScript or Streamline.js, but I hope that wouldn't be what prevents you from using a library that functions/performs just fine.

Without intending to try to "convert" you to either, here's a quick explanation of our code in the hope that it helps you read and understand it:

  • Our classes are written in CoffeeScript's class syntax. It's actually quite simple: http://coffeescript.org/#classes

  • We have one class per file.

  • There are five classes: GraphDatabase, PropertyContainer (an abstract class that's extended by the next two), Node, Relationship, and Path.

  • We only export GraphDatabase.

  • Using the methods on a GraphDatabase instance (like getNodeById, or query, or etc.), you can get instances of the other classes.

  • Streamline syntax is actually extremely simple: wherever you see an underscore (_) in a method signature, that's a callback parameter.

  • Our APIs *do* use the regular Node-style callback convention. The API style generated by Streamline code is identical to any other Node module. (It's in fact better -- calling a method without a callback returns a "future", letting you e.g. parallelize actions more easily. I can explain more on this if you like.)

Btw, in case you haven't seen this already, a while back I built a sample Node.js app -- written in plain old JavaScript, no CoffeeScript or Streamline -- that uses this library:


The models/user.js file in particular is the one that talks to Neo4j:


Hope this helps.

Aseem
Reply all
Reply to author
Forward
0 new messages