Persistent Offline Meteor app suggestions

134 views
Skip to first unread message

EMHmark7

unread,
Feb 5, 2015, 12:31:35 PM2/5/15
to meteo...@googlegroups.com
Not sure netical, put posting here my 2 "answers" posted on stackoverflow.http://stackoverflow.com/questions/10135606/how-can-meteor-apps-work-offline/28255802?noredirect=1#comment44869996_28255802
So not sure they will be noticed as they were posted as answers.

These are some ideas about what could be implemented in Meteor Core, or in partnership with Mozilla or others browsers.

The 2nd post is maybe closer to a solution so you can jump to it.

I am not an expert but let's imagine a solution:

Not on a tablet/cell (not sure we can install a meteor stack on such device), but on desktop, the user needs an offline availability such as point of sale, some transaction logging, a limited or not up-to-date product list, pricing and inventory, etc. (Transactions using stock that is not physically local, should be « to be confirmed (offline order) »  (Locations having that stock could sell even if already reserved by an offline order, that they ar not aware of, because them or the other user is offline, especially if the user having the stock is the one offline)

Beside that, some features could be used only when online (using another Meteor web app)

Of course, not all parts of the application can be used offline: Sensitive record creations, some transactions, searches that need the full collection, etc. The offline features would work through the local machine webserver with a working local full stacked Meteor already installed.

Oplog would sync these offline DB to a mirror collection on the centralized server, one specific DB per user, so not all the big data available offline on user's machine. The idea is to maintain availability of some features. We could otherwise have only one DB for offline transactions of all users, but oplog would sync all these transactions on all user's offline DB. We could POST and clear these records ASAP, but not good for privacy. The best is that client's offline DB – and is mirrored one on the centralized server - would include only records created by that user or info that user could need thus one specific DB per user.

A central server side function would regularly validate and POST these records to the larger all users inclusive centralized DB.

A simple way : All transactions done with local offline meteor app that would post transactions to a webservice when available. (this way, users do not have to manage using 2 applications, going back and forth.)

We could use a concept of 2 invoice numbers : Sale invoice number : generated at transaction time (the document ID?)

Sequential invoice number : for accounting purposes, generated later (when online and for document of 15 to 20 sec. Old. We know for sure all new invoices that created in that period )

The idea here is to have a local meteor stack taking car of local persistance, Oplog syncing with centralized persistance (unless we send asynchrone webservice calls for transactions posting when online, but we loose auto sinc with the larger DB)

(After all, maybe better have 2 applications running: on local, one central served and a way to let these 2 talk together, or an online and an offline app with a comfortable way to direct the user to use the online one in priority and the offline one if offline)

Would be good if the community of more knowledgable people evaluates and document a working way. I did not use yet Meteor, still in the basic learning process.


Bottom of the line:

1) Either the browser can fully save the actual session (every how long? everytime the app requests it because got changes. For such app, every 10 sec is not enough, we need every events). Can we program it in let's say Firefox? (But it would need to save everything (HTML, JS, MinoMongoDB, etc. just for one change!)

2) Or we have a client side full meteor stack taking care of local stuff (a local app of its own) but somehow communicating its CRUD operations to another online app in another tab or instance of the browser. (That 2nd app would be served by the real remote server) The problem is if such 2 apps can communicate. I suppose browsers would forbid it for security reasons)

Another more creative idea could be: Activate oplog on client's stack. Then, every back-online and constantly when online, the actual client's oplog could be exported/imported in the main app (which is another oplog log),

3) Unless we can sent call() request from the client's meteor full stack to another meteor stack on the server. (Is it possible? Is there some rules about URL domain limitations in meteor)

But it does not fix the possibility of having a full meteor stack on a tablet (I am not aware shuch thing is possible)

Marc
Reply all
Reply to author
Forward
0 new messages