Missing things, that came up during evaluating this solution for my app

[RobIsHere]

I'm evaluating the offline realtime solution for my new react native app. I would like to let you know about some things I came about. Maybe they are already solved without me realizing that.

The things that I'm missing are:

• some retry logic for optimistic mutations or an interface for customizing this (maybe pass a custom shareable retry function (serviceName, record, tryNo) => -1, 0..x ms in options)
• start with a partial data set of historical data, that is already locally on the storage of the device
• recheck, correct and update/remove data from the past xx days / past xx records at startup
• make the records store pluggable by defining a store interface (Use case: store the local records in redux, also using normalizr to split nested records that need updates, too)
• some information about resilience (What if the connection drops for some seconds - in a car or train maybe - will feathers-offline-realtime get out of sync? Is there a way to detect this and handle it?)

I think many of these are common things. Hope it helps.

[eddyystop]

Thanks.

• Point 1 is appreciated. I would default to trying 3 times at increasing intervals.
• Point 2 is noted. Perhaps the app can pass a function to call when a snapshot is required.
• I would think point 3 is specific to an application and should be handled by the app. The store would be out of sync with the server.
• Point 4. The store is actually pluggable, but the means to inject an alternate store was not implemented, and only a memory-resident can be used at the moment. I did not want to have to deal with alternate stores during initial release of the repo.
• Point 5. Several people have volunteered to provide a 'connection control' repo for both the browser or mobile, but thay failed to come through. That connection repo would have been used to call connect reinitiating a snapshot.
• Point 5a, The as yet unreleased own- and sync- repos would be able to sync the files in a more efficient way. What's holding them up is that people volunteered but failed to provide feathers-offline-log with support for mobile.

I do plan to return to these repos at some point but I'm focused on other Feathers issues.

Do feel free to submit PRs for any of points 1, 2, 4, 5, 5a.

[RobIsHere]

In the docs I found: "Once the queue is processed, a snapshot refreshes the client's replica, bringing it up to date".

My snapshots would grow to MBs over time. So I'm thinking about a solution, that doesn't transfer the whole snapshot again and again.

Is there another plan, maybe to also have a kind of transaction log on the server for the downward sync? Very interested in your opinion about this...

[eddyystop]

The roadmap includes replication syncing of multiple instances of the same logical file. That gets complicated when many clients can replicate/mutate the same DB. That could be used as an alternative to snapshots.

I don't want to mislead you: that won't be addressed any time soon. There is months of work for the new Feathers release, for rolling out a much faster populating hook, for new common hooks, for rolling out the new GraphQL adapter with code generation. Only then could I think of returning to working on offline.

If you plan to implement this yourself, hopefully each file containa only data for a single user, as a log is then striaghtforward.

If the files are shared by multiple users, then hopefully they are read only. The server could keep a log of mutations organized by a replication-counter. Each client would keep the last replication-count it synced with, and would ask the server for all mutations with larger replication counters. (Many details.)

If the files can be mutated by any of the clients, then each client must also keep a log of its mutations with its own replication-counter. Then the client must first sync its transactions to the server, before the server syncs with it. (Many more details.) The client needs its own replication counter as it may be mutating its records while its also syncing previous mutations with the server. That sync could fail and I found being able to keep the mutations separate was useful.