DEV Community

How would you tackle this? Multiple screens showing the same user generated content in real time.

𝐍𝐚𝐭𝐚𝐥𝐢𝐞 𝐝𝐞 𝐖𝐞𝐞𝐫𝐝 on July 26, 2019

The Problem So I had a project recently in which there were two components: the "app", and the "big screen". Users take their photo with...

Read full post

Nathan Kallman • Jan 13 '21

Sorry to necro; but I couldn't resist throwing my 2 cents at it!

I would add a table to track the "big screen" 's current image (a row for each "big screen", with a foreign key to the images table you have above):

ID	CurrentImageID	Name
1	3	Singapore
2	2	London

Then there's just a few operations to implement:

User uploads new photo: just insert another record in the Images table
"Big Screen" needs a new photo to display: check if that big screen's CurrentImageID is less than the largest ID in the Images table
- if it is: display the image CurrentImageID points to, and increment CurrentImageID to the next one
- if it is not (aka users have stopped uploading pictures for awhile): return a random image and do not increment CurrentImageID
Adding a new "Big Screen"? Insert another row to this table and set CurrentImageID to the most recent image.

𝐍𝐚𝐭𝐚𝐥𝐢𝐞 𝐝𝐞 𝐖𝐞𝐞𝐫𝐝 • Jan 15 '21

Great solution ! Thanks for taking the time to share it :D Don't worry about necroing the thread, it's great to get several different perspectives, as I know a similar job will come around again when we can travel more freely!

How would you trigger the "Big Screen" image check? CRON? OR just "listen" for an image upload?

Nathan Kallman • Jan 15 '21

If I'm limited to just HTTP (so no websockets, server push schemes, or custom protocols) then I would just have the "Big Screen" regularly poll (aka cron) for a new image (maybe 10 seconds?).

If we can use websockets or similar, then that opens the door for fun things of the server notifying screens that new images are available (but then the screen would still make the "request" to get that new image so that it always goes through the same consistent process)

Ken Bellows • Jul 26 '19

Definitely a good case for server-push via WebSockets. I'd make the big screens just dumb clients that connect to the server via WebSocket, listen for images over that socket, and display whatever is recieved. Then whenever the server receives a new user image, it should push it once to all connected big screen clients. Probably no need to even keep the image state around anymore in this architecture.

But that's not to say that your solution was invalid; some platforms still don't have great support for WebSockets (though Socket.io usually takes care of that nicely), and ultimately if your solution worked, then it worked! It's definitely a clever solution!

𝐍𝐚𝐭𝐚𝐥𝐢𝐞 𝐝𝐞 𝐖𝐞𝐞𝐫𝐝 • Jul 27 '19 • Edited

Thank's for your feedback Ken! This is exactly what I hoped to achieve from making this thread. I'd completely forgotten WebSockets were a thing. They're not something I've had to use yet, but you're right this project seems like the perfect time to research how to use them. May even look into refactoring my code; or at least using them the next time a similar project comes along.

and ultimately if your solution worked, then it worked! It's definitely a clever solution!

Thank you! At the end of the day, the client doesn't care what's running on the backend, so long as it works :)

Matthew Dunbar • Jul 26 '19

I would use WebSockets. Then you don't have to worry about timing or marking photos as used. The PHP microsite would get the photo from the app just as it is now, then the PHP microsite can send the photo out via WebSockets to every screen at the same time.

𝐍𝐚𝐭𝐚𝐥𝐢𝐞 𝐝𝐞 𝐖𝐞𝐞𝐫𝐝 • Jul 27 '19

WebSockets! Of course! That's basically what they're designed for right? I'd completely forgotten they were a thing. This is exactly what I wanted to start a discussion like this. I'm the only developer at my company, so I don't have someone I can spitball ideas with; and I guess in this instance I forgot Google existed - haha.

𝐍𝐚𝐭𝐚𝐥𝐢𝐞 𝐝𝐞 𝐖𝐞𝐞𝐫𝐝 • Jul 27 '19

Thanks Neil! Definitely going to research more into WebSockets now and create this project again using them. May refactor the code to include them, but at the very least I'll have a new version the next time a similar project comes along.

Austin S. Hemmelgarn • Jul 26 '19

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.

𝐍𝐚𝐭𝐚𝐥𝐢𝐞 𝐝𝐞 𝐖𝐞𝐞𝐫𝐝 • Jul 27 '19

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!

philliph moxley • Oct 4 '23

Your approach for real-time content on multiple screens is interesting! Instead of a CRON job, consider WebSockets for faster image updates. They ensure immediate display when users upload content. Exploring serverless computing or event-driven setups can boost efficiency. Congrats on the successful project launch and being open to different solutions!