there is a growing movement in the web development community that is rethinking the exchange of data between client and server, especially to write applications that work well offline. Its called local-first web development: https://localfirstweb.dev/
In my opinion, Meteor would also be a good candidate to go in this direction. It offers a clear API to access the data through publications (for reading data) and methods (for changing them). Since the early days, methods are built in way, that data is immediately changed in Minimongo and updated later by the server. Extending minimongo and the server side with synchronization capabilities (or replacing these components altogether) would bring local-first development to Meteor without changing the core data concept of Meteor. I can imagine that apps strictly following this concept could offer offline-capability with no or minimal changes.
There’s a Github issue by @storyteller from 2021 with some discussion: Improve offline support 🛌 · meteor/meteor · Discussion #11656 · GitHub Also this forum contains posts asking for help to build offline-first applications. Unfortunately, I cannot find some kind of best practice to build this feature with Meteor. On the other hand, I’d really like to see this as core feature based on the existing concepts and APIs
I’m all for it, there is GroundDB that needs updating in this regard and would be a perfect fit into this. For now the best start is to implement service workers for now.
What I think is needed in terms of data:
Some way to specify what is needed for full offline usage and then persist that data locally.
When requested by user or when network available sync the data to server or save to file.
Of course there is a lot more, but this is the start, I think.
Since Meteor already includes infrastructure to handle data on the client side it seems that much of the tooling to support offline operations is already in place. Now taking the steps necessary to support actual offline use in a “standardized” way seems a reasonable investment considering the upside. I would just generally very much prefer if the resulting API would prioritize simplicity over features. Reconciling data sets with various degrees of staleness is usually a hard proposition and it is easy to get sucked into a rabbit hole of complexity.
Note that some meteor tool commands are not yet offline compatible either. If I want to run a meteor command while being offline and meteor detected a newer version for update before I became offline then the command halts forever since the download does never succeed.