Do away with node bindings?

[pietgeursen]

I'm wondering about just getting rid of the node bindings and moving to a different solution like a json-rpc server. Or maybe graphql.

disadvantage of node bindings:

• need a fork of knex to make knex open the db in readonly mode.
• node compatibility is still an issue. The current code uses a fixed version of the napi header file. This isn't a great solution as that will change over time. If the code were to get that file dynamically at compile time (is possible) then we need to generate the bindings at compile time and that uses cbindgen and that needs llvm. I think I ran into a block with llvm and trying to build with all the targets.
• the prebuild systems are still not mature. None of them support napi + arbitrary builds eg rust and libsodium that well. Can do it with a hacky fork or prebuild but it's not great and seems like there's a lot of config foot guns hiding there for anyone else.
• I found a bug with having knex + ssb-flumeview-sql trying to share access to the db file. When doing an initial sync, there is so much processing going on that knex is not able to get any of it's queries serviced, I guess because the file is locked. Then indexing and the ui slows down and sometimes knex throws an error about too many pending requests / not enough available resources to make more.

disadvantages of a json rpc server

• it's harder to experiment with new queries. Adding a new query means re-compiling the rust server.

What's a potential path?

• json rpc server that has queries and the process function.
• server is built as a binary for the os's.
• work out how we'd use it as a dep in patchwork. How does xray do it?
• takes paths to the offset file, sqlite db and path / buffer of the sk when started.
• could be a stepping stone to a graph ql api.