I don't think you're wrong here in the assessment of the ease of extending Gremlin Server. We thought we were doing providers a favor by just offering a small set of interfaces they could plug-in to the server, but they never quite offer enough functionality, are at the wrong level of abstraction, etc. We also found over time that there were many more extension points required than were initially needed which took our simple idea for extension and made it much more complicated. That's led to multiple provider forks or folks just dropping to the netty layer for extension. Maybe Guice would help here. It's fairly lightweight and, as far as I know, is not extremely opinionated about things. It would be equal to less work for a provider to learn Guice (if they don't already know it) than it is to learn how to extend Gremlin Server currently. That said, I think that introducing Guice still requires us getting the design for the interfaces right or we could still end up in a place where the provider ends up deep in netty interfaces, so that risk is still there irrespective of a dependency injection framework. It's worth noting that Guice could help replace the current Groovy initialization script used to set up the server. Getting Groovy off of the server is a must-have for 4.x, so if Guice helps do that then that makes sense to me.
On Sun, Nov 23, 2025 at 5:25 AM Andrii Lomakin via dev < [email protected]> wrote: > + Vladimir Grinin , +Lev Sivashov. > > On Thu, Nov 20, 2025 at 3:05 PM Andrii Lomakin < > [email protected]> > wrote: > > > Good day. > > > > AFAIK you prefer to do not force users to lean to one or another > > framework. > > > > But practically it results in the fact that users have to know Netty to > > extend Gremlin Server which is heavier impact than asking users to check > > Guice workings. > > > > Also I have had impression that extention points in Gremlin Server are > > randomly placed and as result have quite steep learning curve. You > > practically need reverse engineer code to find them. Which: > > 1. Contradicting with target to enforce lightweight requirements on > > knowledge of Gremlin Server internals to extend it. > > 2. Usage of IoC will allow to provide systematic approach to extensions > > and makes it more effortless to extend it. > > > > On Wed, 19 Nov 2025, 16:52 Andrii Lomakin, <[email protected] > > > > wrote: > > > >> Good day, > >> > >> Based on my experience, Gremlin Server is currently difficult to extend, > >> often requiring either branching off the code or injecting low-level > code > >> directly into the Netty layer. > >> > >> However, Gremlin Server functions primarily as an Inversion of Control > >> (IoC) framework, similar in principle to Spring Boot. > >> > >> Given that a major redesign is already planned for the 4.0 version, what > >> are your thoughts on refactoring Gremlin Server to use Google Guice as > the > >> main IoC driver? > >> > >> From my opinion it should noticeably simplify integration efforts for > >> vendors including main function such as management of graph instances. > >> > >> > >> Thanks, > >> Andrii Lomakin > >> YouTrackDB development lead > >> > >> >
