Hi Andrea, One more detail I wanted to add: I think splitting the API into distinct structural and process parts is problematic, as it currently prevents users of embedded databases from scaling their applications easily.
One of the key goals of this proposal is to unify these two APIs, allowing users to evolve their deployment schemas—from embedded to remote—without requiring significant changes. I believe achieving this unification is quite important for the broader usability of the system. On Tue, Nov 18, 2025 at 9:14 AM Andrii Lomakin <[email protected]> wrote: > Hi Andrea. > > >Who is the ‘user’ in your proposal? I believe it is a developer who is > using a GLV to query the graph but would just like to confirm. > > Completely correct :-) > > >In your proposal, a user supplies the event handling logic via WASM and > this code is executed on the server, potentially very frequently depending > on the event type it is handling. How can we ensure that multiple users do > not register many expensive event handlers which will then contend for > server resources? > > 1. WASM, by definition, requires a module to specify the amount of memory > it uses. It is part of the WASM module declaration. It is a stack machine > with linearly declared memory. We can easily check limits and reject > incorrect or dangerous declarations. > https://webassembly.github.io/spec/core/text/modules.html#memories > 2. If it is absent, we should limit the number of threads used by user > connections even without the context of this proposal, IMHO. > > >In your proposal, a user supplies the event handling logic via WASM and > this code is executed on the server, potentially very frequently depending > on the event type it is handling. How can we ensure that multiple users do > not register many expensive event handlers, which will then contend for > server resources > > In such cases, the user is limited to data provided by the event, which > limits the scope of applicability of this approach. In reality, it breaks > user abstractions and, as a result, makes this approach impractical for > application developers to use. > Once developers start to implement sophisticated routines, which is > typical for this pattern of data handling, they will soon discover that the > latency of remote access to the server will void the real applicability of > this design. > > > On Fri, Nov 14, 2025 at 7:30 PM Andrea Child > <[email protected]> wrote: > >> Hi Andrii, >> >> My personal experience with event processing has involved either >> server-side business logic or client-side logic that consumes events >> published by the server, so I have a few questions to clarify your proposal. >> >> Who is the ‘user’ in your proposal? I believe it is a developer who is >> using a GLV to query the graph but would just like to confirm. >> >> In your proposal, a user supplies the event handling logic via WASM and >> this code is executed on the server, potentially very frequently depending >> on the event type it is handling. How can we ensure that multiple users do >> not register many expensive event handlers which will then contend for >> server resources? >> >> What are the pros and cons of user-provided WASM event handler executed >> on the server vs a mechanism for allowing users to subscribe to events >> published by the server? I would think that one benefit is that it would be >> faster to implement the user-provided WASM however it would be more >> restrictive as the server should not just allow execution of any code. >> >> Thanks! >> >> Andrea >> >> >> From: Andrii Lomakin <[email protected]> >> Date: Tuesday, November 11, 2025 at 11:03 PM >> To: [email protected] <[email protected]> >> Subject: Re: Proposal: usage of service as foundation for Graph lifecycle >> listeners >> >> Just a small addition Kotlin/WASM and IntelliJ already support DWARF based >> debugging https://kotlinlang.org/docs/whatsnew2120.html#kotlin-wasm >> >> On Wed, Nov 12, 2025 at 7:58 AM Andrii Lomakin < >> [email protected]> >> wrote: >> >> > Hi Andrea. >> > >> > Answering your first question. >> > The use of listeners for changes in entity state as triggers for >> business >> > logic is quite typical for EE applications, especially those with >> complex >> > logic. >> > >> > One of the applications uses them a lot because they use embedded >> > distribution, but I strive to achieve a state where there will be no >> > difference between remote and embedded deployments, and users can start >> > with a small, embedded database and scale it, moving to a standalone >> server >> > or cloud if they later want to scale the load. >> > WASM listeners allow the use of the process API for both cases, no >> matter >> > what deployment they use. >> > >> > As for debugging. >> > GraalVM's WASM engine has announced debugging based on DWARF support as >> an >> > upcoming feature >> https://youtu.be/Z2SWSIThHXY?si=33sxaLmJ26Gob9Aa&t=1127 . >> > >> > >> > >> > On Mon, Nov 10, 2025 at 8:46 PM Andrea Child >> > <[email protected]> wrote: >> > >> >> Hi Andrii, >> >> >> >> Could you please elaborate on the types of scenarios that this proposal >> >> would help users to troubleshoot and how the WASM byte code provided >> could >> >> be used to debug? >> >> >> >> Thanks! >> >> >> >> Andrea >> >> >> >> From: Andrii Lomakin <[email protected]> >> >> Date: Monday, November 10, 2025 at 12:59 AM >> >> To: [email protected] <[email protected]> >> >> Subject: Proposal: usage of service as foundation for Graph lifecycle >> >> listeners >> >> >> >> Good day. >> >> >> >> I would like to propose using the service as a foundation for >> listeners of >> >> the Graph life cycle events. >> >> >> >> It can look like the following: >> >> 1. User creates a service using the provided WASM byte code using a >> >> special >> >> step like registerService(name, wasmByteCode). >> >> 2. User registers the service as a listener for graph events. I think >> that >> >> could be events like vertex, edge lifecycle events, TX commit again >> using >> >> GraphTraversal commands. >> >> 3. During the generation of the event, a special traversal that >> contains >> >> only the affected elements is created, and the service is called upon >> it. >> >> Like `_.inject(elements).call()`. >> >> >> >> In practice, it is advised for each GLV to provide a specialized >> >> implementation of `registerService()` step that will compile the >> passed-in >> >> code into the WASM if possible. >> >> That is possible on Java, and I suppose it is possible for JavaScript >> at >> >> least. >> >> >> >> That will allow us to blur the difference between remote and embedded >> >> deployments, and for vendors that provide both variants to provide >> >> debugging tools for lifecycle listeners when users can test and debug >> >> implementation on their workstation and then deploy in production. >> >> >> >> WASM bytecode was intentionally designed for such use cases. I would be >> >> interested in opinions about this proposal, which is, of course, >> subject >> >> to >> >> a separate specification and many additional clarifications. >> >> >> > >> >
