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. >
