1

So I am working on this mobile application using MAUI, which is backed by a Rest API in ASP.NET Core.

I want to be able to use the app offline, and the user can create/edit some data. This data is store in a SQL lite database, locally on the device. But it has to be synced to the Rest API as well, so the user can get all its info even if he re-installs the app or moves to another device.

What are the best practices regarding this scenario ? Should I systematically try to sync the database with th REST API, or is it ok to sync with the local database, and occasionally to sync with the REST API -> how do I decide to do that ?

If you have any demo sample to illustrate that I am very interested, thanks for any input!

Improve this question
3
  • 2
    The best move is not to play. For many apps, offline support is just "nice to have" and not worth implementing. If multiple offline instances can modify the same records, then you'll need manual merging (like Git) or you're entering an active area of research (→ CRDT). However, there might be "good enough" methods for eventual consistency, e.g. "event sourcing" where you don't sync state but propagate modification events and recompute the current state from that history. But in simple cases, it could be sufficient to back up the database records to the server via a dedicated REST endpoint. Commented Dec 30, 2023 at 22:56
  • Echoing amon a bit. It's hard to say what's best for your app without knowing anything about it. What does it do? What does your research up to this point suggest? Have you run any thought experiments on different approaches? What are your specific concerns? I think crdt's are pretty neat and have used those. But, my latest offline-first app just uses pretty simple timestamp comparisons at the moment, which I may switch to use git-like diffing. But crdt's would be overkill. What you do depends a ton on what you're syncing and the expectations you set for your customers. Commented Jan 6, 2024 at 16:30
  • Just upload the SQLite file periodically. :-) Commented Jan 6, 2024 at 17:41

1 Answer 1

Reset to default
2

Since you mention that your primary use case is to allow the user to use the app offline, and as secondary use case the ability for user to re-use their data if/when they reinstall the app, it sounds like you should not really aim for real-time syncing with the backup database, because the periodical synchronisation will probably provide a decent coverage.

Do you expect your users do mostly be offline when using your app? Then you could implement a variety of syncing scenarios:

  1. Wait for when device has established the Internet connection and perform a single or multiple update operations, depending on how heavy the data payloads are.
  2. Build in a backup as a part of application de-installation procedures - obviously this does not cover the case of phone crashing or user just using a new device and installing your app there.

The REST would be a good choice only if you a) expect the frequency of updates to be rather low, b) the data payloads to be relatively small and c) if you do not intend to use it in cannonical sense, i.e. making a http req every time you are updating a single record only, as it incurs connection setup overhead. Otherwise you'd be better off with a permanent connection/socket based update. Binary connection based protocols like gRPC could be an option too, but again you need to be smart around how you use them - more suitable if you can update multiple records at once, rather than one by one).

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.