This is a fantastic approach.
BTW, it looks like the js engine is "QuickJS" [0]. (I'm not familiar with it myself.)
I like it because sqlite by itself lacks a host language. (e.g., Oracle's plsql, Postgreses pgplsql, Sqlserver's t-sql, etc). That is: code that runs on compute that is local to your storage.
That's a nice flexible design -- you can choose whatever language you want. But quite typically you have to bring one, and there are various complications to that.
It's quite powerful, BTW, to have the app-level code that acts on the app data live with the data. You can present cohesive app-level abstraction to the client (some examples people will hopefully recognize: applyResetCode(theCode) or authenticateSessionToken(), or whatever), which can be refined/changed without affecting clients. (Of course you still have to full power and flexibility of SQL and relational data for the parts of your app that need it.)
[0] https://bellard.org/quickjs/
BTW, it looks like the js engine is "QuickJS" [0]. (I'm not familiar with it myself.)
I like it because sqlite by itself lacks a host language. (e.g., Oracle's plsql, Postgreses pgplsql, Sqlserver's t-sql, etc). That is: code that runs on compute that is local to your storage.
That's a nice flexible design -- you can choose whatever language you want. But quite typically you have to bring one, and there are various complications to that.
It's quite powerful, BTW, to have the app-level code that acts on the app data live with the data. You can present cohesive app-level abstraction to the client (some examples people will hopefully recognize: applyResetCode(theCode) or authenticateSessionToken(), or whatever), which can be refined/changed without affecting clients. (Of course you still have to full power and flexibility of SQL and relational data for the parts of your app that need it.)
[0] https://bellard.org/quickjs/