How to notify your users when a new version is available?

Cyril — Fri, 15 Nov 2024 15:21:20 +0000

Hey folks!

Today, I'd like to share with you a new features we are about to push on Fernand that has been bothering us for a while.

When we were pushing a new version of Fernand in Production, the app tended to have some issues there and there caused by some cache.

So we wanted to implement a notification to tell the user that a new version was released, and they had to refresh their browser.

That's what I worked on today, but I was surprised about the suggestion available online.

Indeed, if your frontend is independant from the backend, how can you tell your frontend that a new version is available?

Well, simple! You just have to create an endpoint on your backend that will receive a Webhook notification on PUSH from Github/Gitlab/etc.

When receiving the request, the server will have a few work to do:

Save locally the new version, in case of reload
Send it to the users when they connects
Send it to the currently connected users.

For both 2 and 3, I searched online, and found two main possibilities:

Using a WebWorker
Having an endpoint in the backend that will show the latest version and compare it with the front. Show the notification when it differ.

Even though option 1 makes a bit more sense, option 2 is really bad because it requires the frontend to query the backend every X minutes, which might cause a DDoS on the server as the app grows in popularity.
Moreover, it's absolutely not efficient, since the delay between two updates could be weeks, months or even years on old projects!

But I wasn't a fan of WebWorker neither, because it required installing it on all the browsers, and the update were only interesting when our users were using Fernand only.

So I come up with another idea. Fernand is relying on WebSockets to exchange data (but stay tuned for a solution when using REST API), so all I had to do, is send a notification to all connected users telling them about the new version.

On the frontend, what I did was store the current SHA1 COMMIT ID as a javascript variable, and compare that to the version sent by the server. If it differs, it means there is a new version available and we show the "Refresh" notification.

The current version is first sent by the WebSocket when the user connects, and when a new version is released, that same Websocket will send the same event with the updated version. That way, in the frontend, we use the same code for both scenarios.

Implementing that in the frontend was relatively easy (I had a much more difficult time finding a way to get the commit ID saved on the app).

But what do to if you are not using Websockets?

In this case, an easy alternative is to provide the current known version of your app as an header when sending your responses back to the client. On the frontend, you can setup a request interceptor to read the responses and compare the "app version header" to the local one and trigger the notification when it differ.

This avoids you to have to setup an interval to check your server.

And in case your user doesn't send much requests to your server, you can query the version to your server when the user gives focus to your app.

So in the end, we have the following workflow at Fernand:

We push an update to Github for the app
Github sends a Webhook event to our servers (dev/prod/etc)
The server will check if the branche matches the server type (branch staging for the staging servers, etc)
If it does, we wait for a few minutes, while the build completes
The new SHA1 COMMIT ID is then saved locally, and an event is sent to all connected websocket to provide the new version

On the frontend, when receiving an event from the websocket about the version, we simply compare the local one against the new one, and if it differs, we show the notification!

Easy peasy :)

Pricing page and currencies

Cyril — Fri, 19 Aug 2022 09:41:00 +0000

Prakash Natarajan wrote an interesting post on IndieHacker on June 20 (Experimenting with /pricing?), where he mentions the issue for non-USD people to have a clear understanding of their cost.

It's true that if you aren't aware of the currency value between USD and the one in your (non-USD) country, you need to do a quick Google search, which isn't ideal and can break your potential user from signing up.

Now, Prakash suggests a simple script that checks the user's country based on his IP, and converts the amount into the local currency, removing the barrier.

But offering your service in multiple currencies can have a big drawback in the future: Imagine the relation between USD and EUR is at 0.7. Your user subscribes in EUR for 7 EUR instead of 10 USD.
A few months later, the relation between USD and EUR changed and is now close to 1. That user will still pay 7 EUR whereas a new user will pay 10 EUR per month.

To avoid this, you can adjust their monthly billing according to the currency value, which is not great for your end user that will never know if they'll pay 7 or 10 EUR.

Having the local currency displayed is a great idea as it can help your user make the decision faster. But instead of changing the currency, and offering multiple currencies, a good alternative would be to show the price in your unique currency (USD for instance), and show the price in their local currency next to it, either as a tooltip, or well-integrated in the design.

That way, your user will know the price is in USD, but will also quickly know how much it will exactly cost for them if they subscribe that day.

What do you think? Those who offer multiple currencies, are you facing this often? Do you consider the variation between the currencies an issue?

Thanks for sharing your thoughts.

DEV Community: Cyril

How to notify your users when a new version is available?

Pricing page and currencies