User Defined Procedures

Neo4j Graph Platform Procedures & APOC
,
1

Hi Neo4J Community,

We are integrating our Neo4j graph database with an application. We are using rest endpoint for an application to query on graph database. It works quite well.

Request Type: Post
EndPoint: http://Neo4JHostMachine:7474/db/data/transaction/commit
Body:

{ 
"statements" : [ {
"statement" : "MATCH (n:CustomerDetails) where n.customerId = '7897987' RETURN n"
}]
}

In Relational Databases we encapsulate data logic in StoreProcedure and Expose only SP name to the application end for data request.

I did little RnD and found in Neo4J it can be done through User Defined Stored Procedures using Java drivers and JARs.

  1. Please suggest, what is the best integration practice of Neo4J database with applications?
  2. Shall we go with the Cipher statement in a request payload or embed Cipher query in Java plugin and call SP over it ?
  3. What scenarios are good for executing a query in Java Plugin in contrast to executing a query statement directly?
2

If the logic that you want to execute can be done in pure cypher alone, do not use a plugin. It's just more work than necessary. You will always be better off using a Neo4j official driver for one of the programming languages, or the transacational HTTP API.

Where you need plugins is when you need to mix and match other Java APIs. For example, imagine two scenarios:

  • I want to integrate with a third party application like SharePoint
  • I want to run some kind of complex algorithm, that for efficiency purposes has to be done in the database (say, matrix multiplication maybe, just an example)

In these cases, you might take a java library and use that as a dependency for your plugin. Your plugin might include custom cypher procedures and functions, so that other cypher clients could:

CALL integration.sharepoint()

These are the cases where I'd use a plugin (when I need to use third party libraries close to the database). If you can avoid plugins and write such integrations externally as clients of the database, this is a better idea.