What Are Optimistic Updates?
How Optimistic Updates May Improve Responsiveness
Hello friends and fellow engineers,
A few weeks ago, I was first introduced to the very interesting concept of “optimistically” updating the user interface (UI). It’s a technique everyone uses to improve the user experience by making the application feel like its more responsive.
There are many times within applications when a user performs an action — like clicking buttons or providing some form of input — and that triggers the application to send a request to a server. In this scenario, the request is going to give some data to the server. For example, if you like a post on Instagram, Instagram will talk to the server and tell the server that you liked that post.
The idea with optimistic updates is that the application will assume that the server will respond “It was a success. You accomplished your goal. Whatever you needed me to do, I did it.” So again, taking Instagram as an example, Instagram will show that you liked the post. A transparent heart will overlay the Instagram post and the heart icon will turn red. Instagram does this, optimistically; they visually show you that you liked the post without first getting confirmation from the backend that that entire operation — of liking the post — was accepted.
It’s such a simple idea, but I thought it was fascinating so I wanted to share it with everyone.
That’s the gist of it. If you want some more details, let’s walk through it.
Walkthrough
You’re on a social-sharing platform. It could be Twitter, Instagram, YouTube, Facebook, Medium... You get it. Again, we are looking at the ability to like a post.
When the user hits the heart or the thumbs-up icon to like a post, the client (browser/app) sends information to a server and lets the server know that the user liked that post. The server needs to know these things so it can handle the data and ultimately share this data with other users.
On top of giving the server that information, the app has to update the UI.
If I liked this post, the heart icon should be filled in like so:
Notice that on social platforms, as soon as you like something, a response is immediately returned to you. Some visual indication will be given to let the user know that they successfully liked the post. In other words, a UI change happens to reflect a change in state.
This is an optimistic UI update.
The user performed an action that changes the state. That action sends information to a server and the UI is optimistically updated to reflect the change in state. We say “optimistically” because we are creating this UI change with hope and optimism that the change in state will be accepted by the server. In this case, after liking a post, we optimistically color the heart red and hope that the backend accepts the user liking the post.
The fact is: we don’t always know if the change in state is going to be valid. Or we do not know if the information sent to the server will be valid or accepted. Instead of waiting for the server’s response — which would confirm that the change in state was successful— we just act like it was successful and we update the UI.
Why do we do this?
We do it for responsiveness.
If we waited for the server to tell us that the user action was successful before conducting a UI change, it would take an unacceptably long time. The product would appear laggy or buggy. The user experience would not be great.
If you like a post, it’s a better user experience to see that the heart icon immediately turns red — indicating you successfully liked the post. It would be an inferior user experience if you liked a post and then saw a loading spinner for a few seconds before seeing that heart turn red. Or it would be an inferior user experience if you liked a post and the heart didn’t turn red until 5 seconds later — when the server finally responds that it was successful.
Loading spinners or second delays are not an expected UI behavior for these types of actions. Nobody does that. It would make users think there’s something wrong with your product.
You don’t want that.
And what if the server does say that it was an invalid action? What if an error is returned from the server?
Everyone does optimistic updates, and products handle optimistic update failures differently. Maybe the solution is to just revert to the previous state? like an undo. Pretend the change never happened.
Or maybe the solution is to throw in a pop-up to indicate to the user that their action was invalid. There are so many ways you can go about it.
In what scenarios can you use optimistic updates, aside from likes?
Binary actions are great for optimistic updates. Like/No Like, Upvote/No Upvote. If the user interface optimistically updates the UI and it was a false positive — aka the server rejected the request — it’s no big deal. Just undo the like and decrement the like count. The consequence of a false positive isn’t going to massively impact the user experience or the application’s behavior. It’s a small fix.
On that note, you shouldn’t optimistically update the UI for actions that will cause major problems if a revert is required. No other component should be affected by a revert. We don’t want a domino effect where there’s a single point of failure. If that component fails, we don’t want the rest of the app to crash.
Another use case is when users — through some interface like an app — create data, update data, or delete data. The users might create, update, or delete data in the Front-End — and the consequences of that are reflected in the Front-End/User Interface. But let’s say that the consequences of those actions are sent to the server, and the server rejects them. This was an optimistic update. Again, it’s updating the UI before you know the server will accept the change in state. If the server rejects it, handle it. Revert it, put in an error pop-up, or do whatever you need to do.
Hopefully that all made sense.
It should be noted that optimistic updates aren’t meant to handle every single user-triggered event under the sun. There are some operations that should be handled client-side, and there are definitely some operations that should be handled by a server. Be intentional with how you do things. That’s all I have to say.
Thanks for reading. Follow me to keep learning with me.
I recently realized that working at AWS is a superpower. There is so much free learning content everywhere. Every single video, document, or instant message can be turned into an opportunity to learn something. I have been loving that and embracing it.
I’ve been learning a lot these past few weeks. Definitely going to keep pumping out some more stuff.
Thanks,
Kyle
