Apache TinkerPop•14mo ago

Reusing connections

Hi, I'm wondering what's the recommended way of using connections to a graph DB. The documentation uses web sockets like so (in javascript)

const gremlin = require('gremlin');
const traversal = gremlin.process.AnonymousTraversalSource.traversal;
const DriverRemoteConnection = gremlin.driver.DriverRemoteConnection;

const g = traversal().withRemote(new DriverRemoteConnection('ws://localhost:8182/gremlin'));

const gremlin = require('gremlin');
const traversal = gremlin.process.AnonymousTraversalSource.traversal;
const DriverRemoteConnection = gremlin.driver.DriverRemoteConnection;

const g = traversal().withRemote(new DriverRemoteConnection('ws://localhost:8182/gremlin'));

but I was wondering if there's a way of opening and managing such connections in an app that uses the repository pattern. I have a frontend that runs queries every now and then and opening a new websocket connection every time I want to run a query doesn't seem too efficient, hence thinking of something like a connection pool managed by the driver (similar to what JDBC drivers do). Is the current advice to have one connection (DriverRemoteConnection) and multiple traversals using that connection or multiple connections, one for each traversal?

Solution:

Connection pooling in Javascript is a bit of an oddity, since the language has mostly been intended for single-threaded purposes (running in a browser). With that, the websocket library native to Javascript hasn't traditionally supported connection pooling natively. In testing we've done within AWS, the Javascript websocket library is by far the most efficient in creating a new connection (single digit milliseconds). Whereas something like Python's implementation can be really expensive (10s of milliseconds, or worse). So maintaining long-lived connections in Javascript is likely not as big of a deal as it is in other runtimes. (My opinion, so take this with a grain of salt). You should really avoid using websockets until you're faced with a use case that would benefit from them. There's a lot of dev overhead in creating and maintaining websocket connections. Websocket connections are also problematic in distributed compute implementations (or for high availability) as they act like "sticky sessions". They can also cause problems with load balancing logic. I would suggest using http requests for as long as you can before relying on the use of websockets. There is obviously the tradeoff of serialization when it comes to using Gremlin with http vs websockets, but that is something you should be able to handle once and be done with it....

Jump to solution

3 Replies

Dragos CiupureanuOP•14mo ago

To add more context to this: I'm writing a web app that needs to update the graph on events happening inside the web app. For this I'm currently abstracting away the graph by creating a service that takes a gremlin query as string in the form of

g.V(<my_id_here>).out().unfold()

g.V(<my_id_here>).out().unfold()

but those string queries become hard to maintain and debug since there's little to no IDE that supports gremlin syntax (or even knows of). Looking at the example given abot I see how that works in an "gremlin 101" way but I'm wondering if that's the correct approach if I still want to expose the functionality of gremlin through a service that abstracts away all the plumbing required to connect to the database and that only acceps a "query" as input.

Solution

triggan•14mo ago

Dragos CiupureanuOP•14mo ago

Great, thanks for the nice explanation. Since the volume of queries in my app is not that hight using http for now should be fine.

Gaming

Programming

Reusing connections