Skip to main content

Realtime challenges

I love the concept of the realtime databases. It enables a more simple application architecture that eliminates a lot of interaction logic when what is displayed on the screen is reflecting the actual state of the database.

With traditional paradigms you'd need to handle the database updates, state changes, data refresh and interface updates separately for every action. For example a simple functionality like marking a message in notifications feed read would require following steps:

- Update message status in backend

- Remove the message item from the "new events" list

- Add the item to the "old events" list

- Update the tab showing the number of new notifications

With realtime database you can skip all but the first step. Everything else will change automatically when the database value updates. You get a lot more done with fewer lines of code.

There is however a trade-off: while you can already trigger those steps 2-4 as soon as the user clicks the link with the traditional method (assuming you also have some sort of fallback for when the backend call fails. With realtime database your user interface will take a moment to update. It requires the backend call to complete first and then the changes propagated back to the client before anything changes. It can make the interface not to feel too responsive, especially with a slow connection.

There are ways to minimize, or hide these delays. You could for example display a progress indicator to the user so they are aware that they action did trigger instead of trying to hit the button constantly. You could also implement the 2nd step from the traditional flow: hide the item as soon as the click triggers. It's the most meaningful indicator for the user that their action went through. There is also an option to use local caches for the data. Handle the updates in the background to the backend database, but to all the actions against the local version to get faster responses.