Skip to main content
  1. Posts/

Four ways to keep backend data synced with your frontend

·863 words·5 mins
Joe Erickson
Author
Joe Erickson
Senior software developer specializing in web development, AI, and helping others learn to code.

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.

Related

Should you always use getters in Vuex?

·1166 words·6 mins
One of the questions that comes up time and again concerning Vuex is “Do I always use a getter when accessing data? Or can I directly access the raw state?” It’s one of those things you hear about that you should do, but no one seems to really explain why. And do you really need to create a getter for every single piece of data that you put in the store? Isn’t that just a bunch of unneeded boilerplate and duplication?

Thank you for seeing my talk at JavaScript and Friends!

·145 words·1 min
Thank you so much for coming out and seeing my talk at the JavaScript and Friends conference (or the video later on). I wanted to give you some extra links to some of the things that I talked about.

Understanding data flow in Vuex

·646 words·4 mins
If you’re like me, when you first ran into Vuex, you probably wondered “How the heck does this work?” It’s not immediately obvious how these types of state management systems work, especially if you come from an SQL background. And do I even need it? In fact, the Vuex documentation has a quote that sums it up pretty well:

Notes and Further Reading for Your Own Personal Bootcamp Talk

·3617 words·17 mins
Welcome to further reading and notes from the Your Own Personal Bootcamp talk. It was great seeing you all at PyOhio this year and I can’t wait to come back again. I hope that, if you were able to see the talk, you were able to pull something away from the talk and had as much fun watching it as I did giving it.

Why should you only change state in Vuex through mutations?

·488 words·3 mins
It’s a common question I’ve seen around and one that I’ve wondered about myself at times. When using Vuex, why is it said that state should only be changed via mutations? Is it really that big a deal? Can’t I just change it directly? It sure seems to work just fine that way.