Any known issues with manually syncing offline devices through a physical server?

Hello,

We are in the early planning stages of migrating from CouchbaseDB to MongoDB Atlas and Realm Sync for our iOS mobile POS application. One of the features we currently offer our merchants is offline sync between devices through peer-to-peer with Couchbase Mobile. From what I understand Realm Sync SDK doesn’t currently have any support for syncing between offline devices through peer-to-peer or multi-tier syncing to a physical server with a centralized Realm. We are wanting to still offer the offline sync feature to our merchants.

We are wanting to move away from peer-to-peer and implement a physical server solution instead. My thoughts are running a mongod instance that our iOS apps can keep up-to-date for our merchants with spotty internet connection. The physical server will act as a messenger essentially, I don’t want to bog anyone down with the specifics of the current design.

Device A saves a document to local Realm Sync while not connected to internet, and sends the document to the physical server through a socket connection. The physical server will emit the document to all the connected Devices B through D. The devices B through D will handle some business logic then save the document to their Local Realm.

I am concerned this could cause problems with the Realm Sync environment, I am not sure what potential issues there are, but it feels wrong to save a document manually synced from another device that will be synced through Realm Sync to all the devices when internet is regained.

Is there any reason(s) I shouldn’t try to implement a solution like this?

Sorry for asking such a hypothetical question.

Thanks.

1 Like

Hi @Kaya_Click, welcome to the community forum!

I just wanted to test my understanding of your requirement…

You’re looking to sync data between devices within a store over a local network, even when that store is disconnected from the internet. When the store is connected to the internet, it can then sync the data with a central copy of the data.

MongoDB Realm Sync relies on devices being connected to the internet to sync data via your Realm cloud service. A device can work offline for hours, and as soon as it gets internet connectivity Realm Sync performs a 2-way sync with the backend Realm service, where changes are persisted in Atlas and synced to other devices.

Copying @Ian_Ward in case he’s seen customers implementing this tiered approach.

What we have seen users do in the past for this use case is to use one of our server or desktop SDKs, like node.js or .NET Core, to implement a type of web server that can be deployed locally at the branch locations - and then clients can use web requests to get or mutate data from this server even when the branch is offline, once connectivity is re-established, any changes will be replicated to the cloud.

So how would we be designing this realmsync wise on the app? Would the iPads exclusively connect and operate off the webserver even when internet is up? Or would we be able to fall back to this only when internet access is down and rely on the normal realmsync capabilities when it is nominal?

@Kaya_Click They would only connect to the Webserver - the mobile devices wouldn’t use realm sync at all, only the Webserver. They would just connect to the local web server via REST. Although you could use a non-sync Realm to store data locally on the device if you wanted.

Of course, this is only needed if you want to support the use case of devices sharing data between themselves while the branch location is offline. For most use cases, we find that using realm sync on the end-client device to be fine since the biggest need from the customer is for the user to be continue to work whether they or the branch is offline - and then replicating changes once the connection is re-established.

Thank you very much @Ian_Ward and @Andrew_Morgan. I like this solution, I’m glad to hear other users have implemented like this.

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.