We have an app that is very update-heavy. There could be tens of updates to the same document from a given client within a minute. This is fine on the client, but we’d like to limit network traffic and server updates, since it’s really only the last update on a document that ultimately matters for the server.
What’s the best way to limit the rate of client requests to the server for updating the database? For example, keep client-side database updates real-time, but keep server-side updates to once every minute per client.
We have a local persistent database that stores the client data, so there’s no risk of data loss on the client in the event that the client closes before the latest update is sent.
A somewhat naive approach would be to just slap a 60 second debounce on those Meteor method calls that update the db. Easy to implement and easy to reason about later on. But will break your UI if you are relying on Meteor’s optimistic updates. But that can often be mitigated with clever use of subtle spinners.
i think the simplest way would probably be to batch / record the changes over a certain time and call a method every once in a while with the current changes or with a new version of the given document / required information / maybe just the changed parts of the document.
If this is a core part of your app it’ll probably be worth it to work on this a bit.
Hmm. Interesting approach. Doesn’t Meteor’s client already batch updates in the case of a lost connection and then sends those updates to the server when the connection is reconnected?
In that case, isn’t Optimistic UI already designed to allow for a fast client database update with slow server database update? I wonder, what’s the best way to leverage that built-in functionality? Just disconnecting and reconnecting every so often?
Yes, Meteor docs do state that in some form method calls are batched and will also run in order (eg here and here). Have not looked into it too much. But I’d be very sceptical on relying on this functionality in your case. Too much magic for my liking. Forcing disconnects and connects periodically already seems suspect.
In general, I’d see the real-time client/server - sync of database tables as more of a prototyping tool. It might match some real-life use case in some cases, but generally most meteor apps don’t use it I reckon.
The usual cycle I use is Client -> Meteor.method-call() -> Server -> Update DB -> Publication -> Results go back to client
-> If you’re lucky you can use the latency compensation of the updating method to update the client database while the call gets sent to the server to be confirmed + committed to the server database.
