Maple currently talks to chDB through direct FFI against libchdb.so. That works, but it means Maple has to maintain its own native loading path, ABI assumptions, and release packaging around chDB.
I would like to propose a small migration step: make Maple use the official chdb npm package as the chDB integration layer, while keeping Maple current user-facing behavior the same.
The first PR would not add durable mode yet. It would only replace the internal chDB access path:
- keep the same Maple UI/API behavior
- keep local chDB working as it does today
- move native addon loading and platform packaging to chdb-node
- add a thin Maple wrapper if needed so the rest of Maple does not change much
Why this helps:
- Maple can follow the maintained chDB Node addon instead of carrying a separate FFI path.
- Durable support can be implemented once in chdb-node, then used by Maple later.
- Future chDB Node improvements, such as async API work, ABI updates, packaging fixes, and platform support, can reach Maple without reimplementing them in Maple.
- The release surface gets smaller because Maple no longer needs to own as much native binding logic.
After that migration is in place, a later PR can add optional Maple durable support on top of the chdb-node durable APIs.
Does this direction make sense for Maple?
Maple currently talks to chDB through direct FFI against libchdb.so. That works, but it means Maple has to maintain its own native loading path, ABI assumptions, and release packaging around chDB.
I would like to propose a small migration step: make Maple use the official chdb npm package as the chDB integration layer, while keeping Maple current user-facing behavior the same.
The first PR would not add durable mode yet. It would only replace the internal chDB access path:
Why this helps:
After that migration is in place, a later PR can add optional Maple durable support on top of the chdb-node durable APIs.
Does this direction make sense for Maple?