移动和ODATA API之间的数据同步架构

Question

我的移动应用程序出现同步问题。该应用程序在线和离线工作。 主要问题包括同步时间，数据压缩和同步中断。 我有一个REST API，为移动设备提供数据和业务逻辑。 Rest API还具有应用程序的身份验证机制。 要同步，移动应用程序具有每30秒运行一次的后台作业（电池消耗问题）。此过程将数据存储在本地数据库（SQLLite）上，并为每个操作进行一些休息调用。有些操作需要在不同的实体上写入，它可以为每个操作发起几次调用，因为其余的实例是基于ODATA协议的实体导向。

目前，我正在研究解决其中一些问题的新方法。

我想，我想进入当前架构的实时数据库......

我有一些场景，但我对这种架构缺乏了解，这使我对最佳场景产生了一些疑问。 我的怀疑是：

• 如果我添加实时数据库（如firebase，realm或其他......）， 我应该将SQLLite数据库保留在移动应用程序上吗？
• 由于我已经有一个rest api来管理数据如何与实时数据库进行通信？应该是我目前的休息 api＆＃34;问＆＃34;到实时数据库更新？
• 可以对通知我当前API的实时数据库（firebase或其他）实施操作吗？
• 网络是否应该演变为使用实时数据库？

对于我在网络上发现的内容，根据每种情况，存在许多可以遵循的方案。但是，我没有找到任何明确的情况。 在摘要中，我的应用程序需要在线和离线工作，并完全与服务器api同步。

移动应用上当前实施的同步机制可能不是最好的。某些操作必须对api进行一些调用并等待处理下一个调用的答案。存在一些业务逻辑来处理这些调用。在服务器端，根据要处理的数据量，某些请求可能会有点慢。 首先，我的观点是在没有同步问题的情况下提高应用程序的性能。