That's really interesting & cool - I'm gonna look into this for sure!
I'd like to mention the Meteor.js framework (https://www.meteor.com/) too, which is in a bit of a transitioning phase right now to Meteor version 3, but is a really amazing full-stack app building solution I and many others have been working with for ~10 years.
It has a lot of batteries included, build system, pluggable frontend frameworks, lots of libraries, based on node.js, meaning it's pretty much compatible with the Node.js environment.
It's based on a really pretty simple syncing strategy for years:
It's original client side data provisioning layer is based on having
a) MongoDB on the Server and
b) a javascript-native implementation of a subset of MongoDB in the Client.
Using a publish / subscribe mechanism the client can subscribe to the subset of data relevant to his current view, eg. dependent on the current user & view.
Updating is theoretically possible by using a syncing mechanism via writes into the client database and an elaborate allow/deny mechanism, but in practice most people use the following simple workflow:
Meteor also provides a method-call-mechanism by which a client can call the server to do (or fetch) stuff. So that's basically RPC in a very simple but powerful format.
These methods also allow for "client side simulations", optimistic updates to the client side database, with the changes getting rolled back / updated once the server part of the method has done it's updating of the database.
So the workflow for working & updating data in the DB looks like this:
- Data is "canonical" on the server DB
- Client subscribes for the necessary data for its client side cache
- When the user triggers an action, the client calls a method on the server, eg: "likePost(post_id)"
- The client side simulation can actually increase the like count on the "Post" document in the local minimongo database
- The server then executes the method & increments the like count in its database, if the request is valid
- The client syncs its database after the method has completed to make sure its optimistic update lead to the same results as the server call did on the server.
- The client updates its UI always reactively as soon as the data in its local db has changed.
All of this is very performant as long as you keep it cool and subscribe only what's actually needed for the current view,
Oh, and all of this has fine grained reactivity, on the client. The whole solution is really powerful, while deceptively simple.
Having the same API on both client and server allows for "isometric" code, meaning code which runs on both the client and the server, so you don't have to have two different versions of helper code, which is really cool too.
Meteor.js is pretty much a bit like "the old PHP experience" to me: As a full Stack developer I can write powerful apps with only one codebase which is shared in parts between client and server.
I'd like to mention the Meteor.js framework (https://www.meteor.com/) too, which is in a bit of a transitioning phase right now to Meteor version 3, but is a really amazing full-stack app building solution I and many others have been working with for ~10 years.
It has a lot of batteries included, build system, pluggable frontend frameworks, lots of libraries, based on node.js, meaning it's pretty much compatible with the Node.js environment.
It's based on a really pretty simple syncing strategy for years:
It's original client side data provisioning layer is based on having
a) MongoDB on the Server and b) a javascript-native implementation of a subset of MongoDB in the Client.
Using a publish / subscribe mechanism the client can subscribe to the subset of data relevant to his current view, eg. dependent on the current user & view.
Updating is theoretically possible by using a syncing mechanism via writes into the client database and an elaborate allow/deny mechanism, but in practice most people use the following simple workflow:
Meteor also provides a method-call-mechanism by which a client can call the server to do (or fetch) stuff. So that's basically RPC in a very simple but powerful format.
These methods also allow for "client side simulations", optimistic updates to the client side database, with the changes getting rolled back / updated once the server part of the method has done it's updating of the database.
So the workflow for working & updating data in the DB looks like this:
- Data is "canonical" on the server DB
- Client subscribes for the necessary data for its client side cache
- When the user triggers an action, the client calls a method on the server, eg: "likePost(post_id)"
- The client syncs its database after the method has completed to make sure its optimistic update lead to the same results as the server call did on the server.- The client updates its UI always reactively as soon as the data in its local db has changed.
All of this is very performant as long as you keep it cool and subscribe only what's actually needed for the current view,
Oh, and all of this has fine grained reactivity, on the client. The whole solution is really powerful, while deceptively simple.
Having the same API on both client and server allows for "isometric" code, meaning code which runs on both the client and the server, so you don't have to have two different versions of helper code, which is really cool too.
Meteor.js is pretty much a bit like "the old PHP experience" to me: As a full Stack developer I can write powerful apps with only one codebase which is shared in parts between client and server.
Link to Pub/Sub docs: https://docs.meteor.com/api/pubsub Link to the Method docs: https://docs.meteor.com/api/methods