Developer productivity is critical for any organization building software. There are many factors to consider ranging from effective communication with the business on requirements to ease of working with the chosen technologies. When the chosen technology is new to the enterprise, understanding the ability to transition smoothly and build a quality solutions with the chosen technology are essential to confidently move forward.
I often receive questions from enterprises around the actual development impact of introducing a database technology that changes the paradigm for reading and writing data — albeit to one that has an immediate appeal for intuitively representing the connections we see in the world around us. About four and half years ago we were in the same position, considering ONgDB for the first time, with a team proficient with SQL and critical project deadlines to keep.
We did it because we saw the potential benefit of the native graph paradigm and our software team today laughs at me if I ever jokingly suggest we may make a wholesale change back to SQL. They laugh because they’ve experienced the benefits of using Open Native Graph Database (ONgDB) and the developer productivity level only continues to increase with each new release of ONgDB.
There are a few consistent benefits of Open Native Graph Database that we have experienced in dealing with connected data throughout the evolution of ONgDB:
- constant time traversals via index-free adjacency avoids the time-consuming dance of normalize, de-normalize, generate view table to squeeze out performance via fewer JOIN operations
- an intuitive property-graph model that is intuitive with contextually relevant relationships avoids the overhead of creating additional, and often complex, application logic to aggregate and orchestrate those connections after retrieving the entities
- the whiteboard-friendly nature of the graph model avoids confusion around the way things are connected resulting in fewer misunderstandings between product/business concepts and engineering leading to incorrect implementations requiring rework later
A major cornerstone in developer productivity was the introduction of Geequel in ONgDB which is a very intuitive and direct representation of the graph data model being queried. Geequel makes it much easier and even fun to interact with ONgDB for read/write operations. The learning curve is very low and the capabilities of the de-facto graph query language continue to improve with each release. When it comes to querying databases, Geequel is a major advantage for increasing developer productivity because there is no longer the constant focus on JOIN operations but rather the intuitive exploration of connected data.
As Geequel has advanced with each release of ONgDB, they’ve include improvements aimed at empowering developer productivity to efficiently create bigger and faster graph-based applications.
Key developer productivity boots in this release:
- Stored procedures, including the provided APOC Stored Procedures, written in any JVM language for more complex database interactions and callable from within Geequel queries
- Deployment with containers such as Docker for development environment consistency across a team and less variation between development and production environments
- Browser Sync for the developer browser to make your queries and settings accessible anywhere
The state of things was very different when we made the transition and in many ways if you’re just now evaluating your own usage of ONgDB, you’ve got a well traveled path to follow with developer-friendly tooling and resources to guide you there. More importantly you have access to those of us that have experienced the technical benefits and business value before you and are equipped to help you succeed.