search

srid / spas

Single-page application server using PostgREST and more
MIT License
32 stars 2 forks source link

Server-side signals #6

Open srid opened 9 years ago

srid commented 9 years ago

Consider extending the notion of signals (Elm, FRP) to the server-side via distributed commit log.

PostgREST requests would be replaced by Signal.send and the corresponding reponse by port Signal.

This would be a killer concept.

rhaps0dy commented 9 years ago

Development-wise, is it so different to having a layer that does SQL requests whenever something arrives to a signal?

Well, this way you could react to events in the database. If you need that then touching the log so it sends to clients via websockets might be worth it :)

srid commented 9 years ago

Well, I'm even getting tired of having to make a request to the server to fetch/send data. Why can't I do it all locally, and have something sync the data in real-time to the server without manual programmer leg-work? Like: https://github.com/paldepind/synceddb

This way, my Elm app keeps all (or a subset) of its model in (browser) memory and directly manipulates it while some other thing will sync it to the server.

What role would the distributed commit log play here? I think it will make the sync simpler to implement. Consider the server maintaining one master update log that records all changes to the database, each update point identified by an auto-incrementing version. Elm app clients would be subscribed to this update log (server -> client log). If the data changes, the server would send this to all clients via the update log. Likewise, the client-side real-time sync thing inside the Elm app would monitor the models and send the change to the server via the same log mechanism (client -> server log). Conflicts would be handled by the client.