Putting it All Together : a Technology Stack on top of a (Neo4j) Graph Database
The above technology stack is explained in this short video.For many practical use cases, one needs a full data-management solution, not just a database.
So, armed with the Schema Layer discussed in the previous part, the next natural step is to add an API and possibly a UI.
This is part 6 of a 7-part series on Graph Databases and Neo4j.
part 1 : Graph Databases (Neo4j) - a revolution in modeling the real world!
part 2 : Neo4j Sandbox Tutorial : try Neo4j and learn Cypher the free and easy way
part 3 : Neo4j & Cypher Tutorial : Getting Started with a Graph Database and its Query Language
part 4 : Using Neo4j with Python : the Open-Source Library NeoAccess
part 5 : Using Schema in Graph Databases such as Neo4j
part 6 : Putting it All Together - a Technology Stack on Top of a (Neo4j) Graph Database
part 7 : (SPECIAL TOPIC) Full-Text Search with the Neo4j Graph Database
The API Layer / Data Manager
The API Layer ("Data Manager") is in some ways the most straightforward layer - because the "heavy lifting" is done by the Schema Layer.
I've been involved in projects that utilized an inadequate Schema Layer - and in those situations the API Layer ends up taking on an immense amount of responsibility that don't logically belong there; the end result being a lot of difficult, error-prone and non-modular development that feels like "pulling teeth"!
By contrast, with a well-developed Schema Layer that provides a wide range of services, it becomes a relative breeze to build an API Layer. The API Layer can then concentrate on roles that logically belong there, such as receiving JSON commands, parsing them, and invoking the appropriate methods of the Schema Layer, which does most of the work.
With such a well-defined modular role, the development focus of API Layer can be to provide a set of useful, convenient, and intuitive request-handling commands, typically for the UI and/or to provide a web endpoint.
The BrainAnnex.org project uses the Flask platform to provide a number of typical operations in this layer - such as to add or edit nodes in the database - and it's fairly easy to add additional operations... or duplicate this layer to meet one's needs.
The API Layer can also take on responsibilities such as:
- authentication
- implementing a master-slave architecture that doesn't require direct Neo4j database support (which would necessitate the licensed version of Neo4j.)
For more information about this layer, please see this short video.
The User Interface Layer
The API Layer takes care of the data management; so that the UI can focus on the front-end user experience.
As far as I'm concerned, excellence in the UI is truly "the final frontier"!
That's the layer that ultimately makes the fundamental difference for the user. Most users won't care if the system has "the engine of a Ferrari", if the vehicle looks and feels like a beaten-up junk car!
All the other layers are in place, and - while there's plenty of room for improvement (and for more documentation) - the foundations are fairly solid and extensive. The UI is a different story; it's the cutting edge of development - and a lot of possibilities exist to explore.
The BrainAnnex.org project uses the Vue.js platform and the Cytoscape.js library to provide a dual modality for displaying/editing data: tabular form and graph form ("balls and edges".)
Also, BrainAnnex makes use of a Class-based UI, whereby some of the data Classes (as defined in the Schema layer) are associated with ad-hoc software ("plugins") to display/edit data of that class in a particular manner. Historically, the early versions of BrainAnnex utilized this approach to implement a multimedia content management system - but now that's just one use case.
The UI Layer is a very active area of development. Just like for the API Layer, one might opt to supplement, based on one's needs, the existing layer provided by BrainAnnex - or replace it with a custom one.
Things start getting especially exciting and powerful when the UI is aware of the different data types (for example, as specified in the Schema layer described in the previous section), and has the capability to personalize the display and editing mode of data records based on their types ("classes") - perhaps with plugins to provide modularity and easy expansion.
Well, that's exactly what the new version (5) of the open-source project Brain Annex does! As of Aug. 2023, it's in a late Beta stage - with the exception of the bottom-most layer, the NeoAccess library (which exited Beta.)
One use case of such a system is to be a multimedia content management system, which is what the old ("vintage") versions of Brain Annex were, before switching to being Neo4j-based, which leads to a far more general system.
Armed with an API, and possibly a UI, one can for example create a standalone web app, or a control panel for an existing website or web app. For example, the diagram at the very top of this page is how Brain Annex does it.
For more information about this layer, please see this short video.
Special-Purpose Modules
Now that we have a whole technology stack, how about looking into special-purpose modules? We'll do that in part 7, with a discussion (and available open-source implementation) of full-text search!
This is part 6 of a 7-part series on Graph Databases and Neo4j.
part 1 : Graph Databases (Neo4j) - a revolution in modeling the real world!
part 2 : Neo4j Sandbox Tutorial : try Neo4j and learn Cypher the free and easy way
part 3 : Neo4j & Cypher Tutorial : Getting Started with a Graph Database and its Query Language
part 4 : Using Neo4j with Python : the Open-Source Library NeoAccess
part 5 : Using Schema in Graph Databases such as Neo4j
part 6 : Putting it All Together - a Technology Stack on Top of a (Neo4j) Graph Database
part 7 : (SPECIAL TOPIC) Full-Text Search with the Neo4j Graph Database
Comments
Post a Comment