> but who computes the "update" node, and from what data?
I was thinking of a light layer over the SQLite FFI, so something like:
`watch_query("select..", handleEventFunction)`
This would be the same process, but possibly different languages (E.g. C inside a Python program).
I think there would need to be ratelimiting. If there are 100 writes per second you may want to try and wait until the writes stop and then re-run the query.
> Laudable in principle, but only worth doing if it's actually a net improvement, all things considered.
This is how React and most other front end JS works by default. Most Google web apps do this for example. It is worth doing because the API between the JS VM and the DOM is slow compared to a JS function just updating a JSON structure - so React computes the smallest diff, then uses the slow DOM API to write changes all in one batch.
> A web server is typically 10-20 ms
The minimum to the closest CDN is likely 35ms. But any solution has to accept this.
Personally I prefer the diff based API because:
- If your result set has 1000 rows, and only a few change, you are only sending the changes over the APIs.
- `SQLite -> Host Language -> Network, maybe -> View`