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