One big question people have when building frontend applications is, what’s the best way to keep backend data synced with my frontend data? You seem to always get different answers from different people and the dreaded “It depends”. Well, what does it depend on?

Here are the four main ways that developers keep their data in sync and the reasons why you might choose one over the other.

1. Refresh data on every action

You could refresh the data on every action that the user takes. User opens the app? Pull the information from the backend. User views the list of pictures they saved? Repull the information from the backend. User saves a new picture? Save it, then repull the information from the backend. This is very useful when

This is typically a perfectly reasonable way to start out and is the technique that most developers come to when first starting out. If your data is not too heavy, this is probably the main way to go. I’m a fan of avoiding premature optimization and so would recommend this to any dev just starting out.

This is especially true if your application has data that only this user will be editing. If there’s no real fear of the data changing on the backend when the application is running, then there’s no need to change the data unless this user changes it themselves.

Users would expect this kind of behavior in any application that is essentially single user, like a nutrition tracker or bookmark manager.

2. Add a refresh button

You could refresh the data only when a user clicks on a refresh button on the page. This puts the responsibility for getting new information from the backend on the user, but can cut down on the number of network calls that your application needs to make. This could either be an explicit button or, in the case of mobile apps, a swipe down on the screen to trigger a refresh.

There are many applications that follow this approach. If real time data is not vital to the application, a nice refresh button on the screen can allow a user to update the data when they want it to update.

There are many times when updating data when the user doesn’t expect it could lead to confusion on the user’s part. YouTube’s Trending channel follows this convention on mobile and Twitch will not real-time update the channel list either. If they did, as new information came into the system, the user would be constantly trying to hit a moving target. Better to show them the current recommendations right now and let them tell you when they want a new set of data.

3. Periodic refresh

You could refresh the data every five minutes or half an hour. By setting a timer and refreshing data when the timer is up, you can keep the screen refreshed with the latest information without overwhelming the user or your server. This used to be how many of the browser-based email clients worked (and some probably still do) but I will say that most of them have moved on to using the next method that I’ll talk about.

If your application is kept in a tab and left to run often and alerts don’t need to be delivered the minute they happen, this can still be a useful technique to follow.

4. Push Notifications

The last technique is called Push Notifications on mobile and implemented with either Web Sockets or Web Push. (It used to be called Comet, but the technique that describes is long past its prime.)

This is when the backend pushed data to the client instead of the client asking for data from the backend. When the frontend starts, it registers with the backend that it wants real time data updates and then, when something comes into the backend that the frontend needs, the backend will push that information to the frontend right away.

Think any chat application, from Facebook Messenger to Google Hangouts. They are using some form of Push Notification, but so is Slack in your browser window. Use this when users want information right away and a delay wouldn’t be acceptable.

All together now

While these are all very distinct methods for updating data, they are best used together, depending on the circumstances outlined above. If I’m looking at my Twitter feed on mobile, Twitter will use periodic checks to see if I have any updates (option 3). If I have an update, it will enable a “See X new tweets” refresh button that I can click to pull the new data (option 2). And if I’m on my user profile page, it won’t attempt to load in new data at all until I click out of it and back in (option 1). Every app is going to pick a different technique to use depending on what user experience they want the user to have.

So look into these different techniques for your frameworks and think about it this way, What does the user expect to happen? That’s the best way to choose how to sync your data.