Trigger page-reload on new deployments
Hey everyone,
I'm working on a project and need some advice on how to efficiently implement functionality to trigger a page reload when a new deployment is triggered. This implementation needs to be able to scale across different servers behind load-balancers with 100k active users in peak periods.
Here's what I have in mind:
WebSocket Connection: Maintain a WebSocket connection to listen for deployment events from the server.
Polling: Use a polling mechanism to regularly check for new deployments.
Has anyone implemented something similar or have insights on the best approach? tips would be greatly appreciated!
Thanks in advance for your help!
5 Replies
Websocket connections are expensive, especially for such a high amount of users.
If you use them for this task ONLY, i would advice to use polling - if you have a websocket connection running anyway, you could request the version on connect as you will disconnect while restarting the backend (in case you have one).
You did not state if you have a backend running or not. If so, create and API endpoint that exposes the current active version.
If not, put a version.json in your public/ folder that holds the version information. Be sure to NOT cache this file (you might want to query it using a ?timestamp=<> querystring).
Be sure to only reload if the version goes up, not down (as your updates might not roll out at the same time).
@Single Thanks for the reponse! It seems you have good knowledge so sorry for ping but I what do you think about this approach?
I have an external Laravel backend running but I'm proxying all my requests through Nitro to this external backend. I could easily create an endpoint for this my question would then be where to store the "deployment ID" for optimal performance?
I'm thinking of two options either KV storage in Nitro or just a static file in the assets/ folder. I assume 100k users polling my KV storage could become quite expensive so static json file seems the best?
I'm thinking a deployment script that creates a file in the assets/ directory with a deployment ID and then an endpoint like this:
export default defineEventHandler(async () => {
const data = await useStorage('assets:server').getItem(deployment.json)
return data
})
that will be polled by my frontend like this:
export default defineNuxtPlugin(() => {
const { deploymentId } = useRuntimeConfig().public
const interval = setInterval(async () => {
const response = await $fetch('/deployment')
if (response.deploymentId != deploymentId) {
reloadNuxtApp()
clearInterval(interval)
}
}, 5000)
})You said that you have multiple servers - depending on your loadbalancing strategy, it is possible that your nitro/frontend jump between Server A and Server B which can be of different versions, thus using
if (response.deploymentId != deploymentId) { could make your frontend reload everytime you see a different version. I would try to ensure that it only reload if a HIGHER version has been detected.
I assumed you want to reload the frontend after updating it, but it seems that you want to reload the frontend whenever you update your backend.
If you build a new server+client anyway, why not just set a string with the versionnumber within the nitro endpoint. I usually set the string with the .version number of my package.json as we increase it using semantic release anyway, and its guaranteed to be a ongoing version.
If you use your frontend > nitro > laravel, i would cache it for sure on the backend for x seconds to reduce the amount of calls.Alright thanks a lot!
I haven't thought of the possbility of a reload-loop if my frontend sees different versions of my backend. Wouldn't it still techincally be possible to trigger multiple reloads in a row if my frontend detects a new server A build, reloads and reaches server B which is still deploying?
We haven't had the need for more than 3 servers so far but definitely a good point.
As for the endpoint I think I thought too hard about it. Simply returning a string set during build time and caching it for a short duration seems like a simple and easy solution.
Yes it would, thats why you should only reload your interface in case there is a newer version string detected. If your frontend mailfunctions while working with an older version, than you should downgrade.
You can configure your Loadbalancer to work with sticky sessions to avoid this problem: https://medium.com/@iSooraj/how-sticky-sessions-can-tilt-load-balancers-c5dc8f50099c
Medium
How Sticky Sessions Can Tilt Load Balancers
In the world of Software Engineering, efficiently managing incoming requests across multiple servers is a critical aspect of building…