I'm a Systems Reliability and DevOps engineer for Netdata Inc. When not working, I enjoy studying linguistics and history, playing video games, and cooking all kinds of international cuisine.
I'd structure things with a server-push architecture instead of a client-pull architecture. Such an approach has a couple of specific advantages:
It means the 'big screen' component can be tiny. It literally just has to connect to the server and then update the display every time it gets an image. That could probably be done in less than 16kB of minified Javascript with zero external dependencies provided you restrict it to running on a sufficiently new browser.
If you ever decide to change the update interval, you only need to update the server side, and the change would take effect for everyone the moment it's deployed on the server.
Because the server is picking and sending the images, there's no chance of the client not getting any image (you mentioned you were using SQL, you can actually achieve this there too by grouping the state updates into a single transaction, though in that case some clients might miss images instead of just getting nothing back).
Because the server is pushing things out itself, it's easier to scale by fanning out through proxies. An architecture like this can easily be made to support anycast addressing too.
As far as how to do it, there are literally dozens of options. I'd probably go with a PWA and use the Push API from the app's service worker. From there, it just amounts to a bit of extra server-side logic to actually push things out.
Luckily we can control which browser the "big screen" will use. As it won't be something which is launched to the wide world to access, we can ensure we use newer browsers. So thankfully we're open to new technologies!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'd structure things with a server-push architecture instead of a client-pull architecture. Such an approach has a couple of specific advantages:
As far as how to do it, there are literally dozens of options. I'd probably go with a PWA and use the Push API from the app's service worker. From there, it just amounts to a bit of extra server-side logic to actually push things out.
Thanks for your suggestions Austin!
Luckily we can control which browser the "big screen" will use. As it won't be something which is launched to the wide world to access, we can ensure we use newer browsers. So thankfully we're open to new technologies!