Building a Graph Database Application - Graph Databases - page 78

this extension exceedingly testable. As we'll see later, in “Testing server exten‐
sions” , we can unit test extensions without having to run them inside a server.
Server extensions can be powerful elements in our application architecture. Their chief
benefits include:
Complex transactions
Extensions enable us to execute an arbitrarily complex sequence of operations in
the context of a single transaction.
Choice of APIs
Each extension is injected with a reference to the embedded graph database at the
heart of the server. This gives us access to the full range of APIs—Core API, traversal
framework, graph algorithm package, and Cypher—for developing our extension's
behavior.
Encapsulation
Because each extension is hidden behind a RESTful interface, we can improve and
modify its implementation over time.
Response formats
We control the response: both the representation format and the HTTP headers.
This enables us to create response messages whose contents employ terminology
from our domain, rather than the graph-based terminology of the standard REST
API ( users , products , and orders for example, rather than nodes, relationships, and
properties). Further, in controlling the HTTP headers attached to the response, we
can leverage the HTTP protocol for things such as caching and conditional requests.
When considering using server extensions, we should bear in mind the following points:
JVM only
As with developing against embedded Neo4j, we'll have to use a JVM-based lan‐
guage.
GC behaviors
We can do arbitrarily complex (and dangerous) things inside a server extension.
We need to monitor garbage collection behaviors to ensure we don't introduce any
untoward side effects.
Clustering
As we discuss in more detail later, in “Availability” on page 157 , Neo4j clusters for high
availability and horizontal read scaling using master-slave replication. In this section
we discuss some of the strategies to consider when using clustered Neo4j.