|presents ideas for future development directions of JCypher and other graph database related ideas
(this section is ment to evolve over time)
JCypher as a Service
JCypher provides quite a couple of powerful features, especially concerning the handling of complex business domains. With these functional features and with non-functional features like transactions and concurrency support in place, it seems to make sense to extend JCypher's design, enabling JCypher to be run as a service.
By providing a RESTful interface, it shall be possible to deploy and use JCypher in a distributed, possibly heterogeneous environment.
A first step in that direction was done by implementing a 'Generic- (Dynamic-) Domain Model' (please see the previous post), which was introduced with release 3.0.0. The next step will be to implement a 'JSON-Facade' which can be invoked by a service-capsule, in order to provide a RESTful service interface to JCypher.
After the 'JSON-Facade' is in place, I plan to introduce a new project 'JCypher-Server', which will provide a server-side implementation of JCypher together with a browser interface, allowing to explore and work with 'domain graphs' based on JCypher features.
Generic- (Dynamic-) Domain Model
The domain model, i.e. the model of a domain graph (graph of Java objects) which is stored to / retrieved from a Neo4j graph database by means of JCypher 'Domain Mapping' or JCypher 'Domain Queries' respectively, is specified by those object's classes.
If you don't have access to these Java classes, a generic- (or maybe better a dynamic-) domain model comes in handy.
Here are some scenarios, which would highly profit from such a dynamic domain model:
Domain Queries - A powerful approach to analyse and query business domains
(Was started with JCypher release 2.1.0 and extended step by step in the following releases).
At a higher level of abstraction, JCypher provides mapping of arbitrarily complex business domains to property graphs (Neo4J). Firstly, a default (generic) mapping is provided, which allows domain objects ('graphs' of pojos (plain old java objects)) to be stored to a graph database in a straight forward way. No additional configuration except for database access is needed. Simply construct your domain objects, instantiate a DomainAccess and call store(domainObjects) --> domainObjects is a list containing the objects you want to persist. The 'graph' of domain objects is mapped to and stored in the graph database.
Additionally, configuration of how to map domain objects to elements (nodes, relations) of a graph database, by means of a 'Native Java DSL', is (will be) provided. That is especially useful, if you want to map a graph to a domain which did not originally create the graph.
While a major advantage of the previously mentioned approach is the ability to easily persist and retrieve domain objects without the need to design and configure complex database schemas (as e.g. with relational databases), the true power comes from the fact that the 'graph' of domain objects is backed by a graph database (Neo4J). It allows to execute powerful queries on your business domain performing complex navigations of the object graph, because the queries are actually performed against the graph database.
As a simple example think of an instance of a class Person which contains a list addresses, holding objects of type Address. To query a person for its addresses is straight forward. But given you have an Address and you want to know all Persons who live at this Address, a traditional approach is of high complexity and mostly of poor performance. You would have to iterate over all Persons and test each one if it is related to the specific Address in order to collect those Persons.
Now when your business domain is backed by a graph database, the link between Person and Address is explicitly stored as a relationship and can easily be traversed in both directions. No need for joins (which often bear performance problems) as with relational databases. The more traversals you want to do in your query, the more advantage you gain when having your domain backed by a graph database. JCypher provides (will provide) a powerful 'Domain Query Language', which strongly inherits from the graph query language 'CYPHER' or JCypher's 'Query-DSL' respectivley. But in contrast it allows to formulate queries on the domain objects or their types respectively (instead of formulating queries on nodes and relations of a graph).
Future development directions for JCypher
Some general ideas concerning graph databases
After some time working with Neo4j, I am convinced that graph databases are not only the best solution for storing and of course for retrieving highly connected data, but also for storing and querying many of today's application's data.
I would even add a plus for the schema free approach. Usually, in solutions with relational databases as backend, constraints and business rules are split between schema definitions on the database and constraints implemented in the application code. I would prefer having all those constraints and rules in a single place.
My feeling is, that graph databases have the potential to substantially change the way how we architect, design, and implement our applications in the future (maybe also how we model them). I think e.g. about relations or relationships as first class citizens in our design of application models.
Let's construct a simple example about Person(s) and Address(es): In one application domain we could be interested in relationships between Person(s) and Address(es) (e.g. a sales application (relationship: shipTo)). In another application domain we could be interested in relationships between different Persons (e.g. a social media application (relationship: friends)). In common approaches that we apply today, reusing Person across different domains would be very difficult (if not impossible). Why?: For domain 1 (sales application) we would design a method getShippingAddress() in class Person, whereas for domain 2 (social media application) we would design a method getFriends() in class Person.
In that way we end up 'enriching' class Person with a lot of navigation methods, of which we are only interested in a small number in the context of a single domain.
Alternatively, viewing relationships as first class citizens of a domain (relationships actually structure a domain), we could end up with domain specific relationship classes such as SalesApp and SocialApp. These classes then would implement domain specific navigation methods: e.g. SalesApp.getShippingAddress(Person aPerson); SocialApp.getFriends(Person aPerson), thus allowing us to easily reuse class (or entity) Person across different domains (without polluting it with navigation methods of many different domains). This idea is strongly impacted by chapter 'Cross-Domain Models' of the book 'Graph Databases'. This shall be seen as just one example of how graph databases might influence (change) the way we design our applications.