Generally speaking, I think this idea begs to be explored but I also think that it's a change of extraordinary size that will need a lot of thought and planning to be sure it is done properly. I think initial efforts with that plan are already underway with 3.8.0 where it introduced the notion of StepContract interfaces and "step placeholders" which should allow providers to more easily provide their own implementations. In this way, a provider would be implementing at a Gremlin level rather than at that Structure API level. So, that's a starting point to allow for any of this to happen. I don't recall past discussions about what happens to Element interfaces, but I sense they would end up being read-only as you described. I suppose they would stay interfaces and there would be a few concrete TinkerPop implementations that we'd offer for providers to convert to when implementing steps. Remote providers might skip all that together and just write directly to GraphSON or GraphBinary.
I don't know if transactions should explicitly be implemented as a traditional Step or not. They don't behave like steps in my mind, in that I don't see how they chain. Maybe it's more like a terminal step or a special step series like io().read()/write(). I think the first work to be taken around this big topic is to try to build consensus for what transactions look like, both as a part of the Gremlin language and the HTTP API. I know Ken has been thinking about the Transaction API for 4.x, but no formal proposal has been raised yet that I can recall. I will add that while I feel the Transaction API is a must-have for 4.x, I'm not sure that I see removal of the Graph API as a critical item for that version. If there was consensus on a plan to do so, I think it would be best for that to fall into a later body of work where perhaps the deprecation for the Graph API is in 4.x with removal in 5.x. On Sat, Nov 22, 2025 at 8:49 AM Andrii Lomakin via dev < [email protected]> wrote: > Dear like-minded colleagues, > > Sorry for the stream of ideas, but I wanted to share my thoughts on API > dual support. > > I believe the dual support of two API types—structured and process—is > counterproductive because it prevents the creation of truly > platform-independent distributions. > When an application development team begins to rely on the structured API, > they become limited to a minimal number of vendors who support embedded > deployments. > > Furthermore, I agree with Stephen Mallette that it is more straightforward > and more idiomatic for a provider to implement a few basic steps that > operate on database records than to implement the more demanding interface > of a Graph instance. > > In practice, this suggests the following changes: > > 1. Remove the Graph interface as a public API. > 2. Make the Element, Vertex, and Edge concepts read-only. > 3. Add steps to control transactions uniformly at the GraphTraversal level > to unify management. > > Regarding transaction management, the current implementation appears to be > an ununified side feature, especially considering the disparate lifecycles > between embedded and remote deployments. Introducing steps that control the > transaction lifecycle would resolve this issue. > > What do you think about these points? > We will consider implementing those items on our side in the short term. > > Best regards, > Andrii Lomakin > YouTrackDB development lead. >
