Fast and Resilient with Offline-First using RxDB
Let's talk about a challenge every developer knows all too well: making apps work smoothly regardless of network conditions. At Synap, we faced this head-on while building Didit, our Request Management System (RMS) that we're about to release. We wanted to create something that would change how people think about managing tasks and requests and frankly, to stop using messaging systems such as email to send requests -- it's just not trackable.
What Makes the Didit App Different
Didit lets you make requests of individuals or groups, track assignments, and get notified when things are completed or past due. You can assign tasks to each person in a group individually, create collaborative assignments for team efforts, or set it up so the first person to accept "claims" the task. Assignments can have specific deadlines or recur regularly, and they can include checklists, questions -- pretty much anything you need to get work done.
We knew that for an app like this to really shine, it needed to be reliable in any situation. Traditional apps start throwing up loading spinners and error messages the moment your connection gets spotty. That just wouldn't cut it for Didit.
Think about your typical workday. You're assigning tasks on the elevator, checking updates while walking between meetings, or completing assignments on your commute home. These are exactly the scenarios where network connectivity becomes unpredictable -- and exactly when you need your tools to keep working.
That's why we went all-in on an offline-first approach using RxDB.
The Case for Going Offline-First
Users now expect applications to "just work" even when they lose connectivity. Whether they're on a plane, in a basement, or just switching between networks, losing data or being blocked by a loading spinner is no longer acceptable. Offline-first design prioritizes local operations first, with background synchronization handling remote persistence
We wanted Didit to stand out, to not only provide the best features for its use, but to also be one of the most reliable and performant apps people use. Our goal is zero downtime. I know, everyone has this goal, but our belief is that with an offline-first architecture we have a strong chance of achieving zero downtime. Why? It's in the name, "offline-first". This means that the server could crash hard and users would just keep creating new tasks and completing tasks they have. Then when they are back online, the data gets sync'd in the background. Most short outages or slowdowns will never even be noticed.
Speed matters. I know a lot of developers believe in the idea that you come back and address performance issues after they are recognized. While I agree with this for many code performance issues, I think architecting for performance is important. Each application is different, but with our Didit app it made a lot of sense to keep user task data stored locally so that the app is super fast as well as the data you need always being available. .
RxDB is purpose-built for this philosophy, and it became the foundation of how we built Didit.
RxDB, At the Heart of Didit
RxDB is a reactive, client-side NoSQL database built on top of IndexedDB and other browser-native storage engines. For our app, it provided several crucial capabilities:
Reactive data handling: Changes to documents are streamed in real-time to subscribed components, aligning perfectly with our reactive approach in Angular.
Local-first performance: All reads and writes happen locally first, ensuring near-instant responsiveness. There's no waiting for network roundtrips when you mark something complete or assign a new task.
Replication and sync: RxDB offers robust synchronization mechanisms to and from remote endpoints when connectivity is available, managing the complexity of keeping everyone's data in sync.
Flexible schema definitions: We defined our schemas in JSON, enforced them at runtime, and could easily evolve them as Didit grew to include more complex assignment types.
Seamless Fit with Our Framework
Our choice of Ionic and Angular as the foundation for Didit turned out to be incredibly complementary to RxDB's capabilities, although it works with any framework. RxDB pairs naturally with Angular's reactive forms and dependency injection system. With Ionic, which brings native-level mobile experiences to Angular apps, RxDB helped ensure that those experiences remained fluid even in low or no network conditions.
The ability to persist data locally in a structured way aligned perfectly with what our users expected -- an app that behaved like a native application, not a website that breaks when offline.
The Magic of Real-Time Updates
One of the coolest parts of our approach is how everything updates in real-time. We leaned heavily on reactive programming principles, using observables and signals throughout the app.
What does this mean for Didit users? When someone on your team marks a task complete, you'll see it happen almost instantly. When a date changes, everyone gets the update right away. When a group assignment gets claimed, it immediately reflects for all team members. The whole experience feels alive and responsive.
This wasn't just a nice-to-have -- it was essential for a tool where timely information matters. Imagine waiting 30 seconds to find out someone else already claimed the task you're looking at. That kind of lag creates duplicate work and frustration. So many other applications today force users to click the Refresh button to see updates -- how old fashioned.
Why Request the Same Data Over and Over?
In traditional apps everytime a user requests the same page the app is pulling that data from the database again and again and again. With the offline first approach you only request what changes one time, then you have it locally. This means a significantly reduced demand on the servers.
One of the things we love about RxDB is the ability to control what data syncs to whom. We can easily keep anyone assigned or watching a task updated and they only receive the data they need.
For the mobile version of our app we'll be sending updates via silent push notifications, so everytime the user switches to the Didit app they will already have updated data, no waiting.
Staying Smooth When Servers Hiccup
Here's where things get really interesting. Traditional apps fall apart the moment there's a server issue. But with Didit, you might not even notice if our backend slows down or needs maintenance.
Because your app is working primarily with local data, temporary server problems don't interrupt your workflow. You keep assigning tasks, updating statuses, and checking things off your list. When the connection improves, everything syncs up automatically in the background.
This resilience is a game-changer for business tools. No more "the system is down" excuses -- your work continues uninterrupted.
Seeing Double: Planning Your Data Architecture
Using an offline-first approach is more complex than it might seem at first glance. When building Didit, we quickly learned the importance of carefully planning both server-side and client-side data structures -- and understanding how they differ.
You need to think through each transaction and how it behaves in both online and offline scenarios. In our experience, we discovered that data doesn't always flow equally in both directions. Some information in Didit made sense as pull-only from the server. Other data worked better as push-only to the server.
Another realization was that while most changes in our RMS would originate from clients (people creating and completing tasks), the server still needed to be the authoritative source for certain data fields. Establishing these dependencies early will help you.
Yes, it's certainly a challenge to map out all these data flows and sync strategies. But once you have it working -- once your users can seamlessly create, assign, and complete tasks regardless of their connection status -- the payoff is absolutely worth it. For Didit, this foundation of reliable data management became the invisible infrastructure that lets the user experience shine.
Premium Features for a Boost
While building Didit, we're leveraging several of RxDB's premium packages to further boost the performance and capabilities of our app.
For our web app (PWA) we will be using the IndexedDB RxStorage engine. For our iOS/Android mobile app builds we will be uing the SQLite RxStorage engine. For even faster performance amd better local encryption we're wrapping the storage engines with the Memory-mapped Storage and the Web Crypto plugins.
The Bottom Line: Was It Worth It?
Building Didit as an offline-first application wasn't the easy path. It required more upfront design, careful thinking about data flows, and sophisticated conflict resolution.
But the payoff? An app that just works, all the time, for everyone.
For a Request Management System like Didit, this reliability transforms the user experience. No more lost updates when your train goes through a tunnel. No more waiting for slow API responses when you're trying to quickly assign a task. No more frustration when the coffee shop WiFi drops just as you're updating a deadline.
As we prepare to introduce Didit to the world, we're confident that this approach -- while challenging to implement -- will deliver something special: a Request Management System that's as reliable as it is powerful. An RMS that works wherever you do, without excuses or interruptions.
After all, isn't that what technology should do? Get out of your way and just work?
We're obviously huge fans of the RxDB library, so please if you think an offline-first approach might be valuable to your project, please contact us with any questions you may have. You can also check out the RxDB website and documentation for more technical details. There is also a great artical titled Local First / Offline First that I recommend and another titled Why Local-first Software is the Future.