I feel like these used to be a bit more popular, so writing about this project after the fact you’ll need to jog your memory on these sorts of setups. They’re referred to as either hashtag walls or social media walls. They were mostly used at events, and they would create a sort of live digital photoframe by displaying images from public social media that contained a specific hashtag. The event-specific hashtag would be known to event-goers, and if they included the hashtag in their public post then their photo would periodically be displayed on a large TV at the event. Sometimes they are still used at sporting events and displayed on the jumbotron.

Before the Twitter API was paywalled, I wanted to setup a hashtag wall for an event that was coming up. However, there were not any suitable free solutions for this at the time. As it wasn’t a hard requirement for the event, I figured it wouldn’t be too hard to DIY a solution with some custom code. I also wanted to experiment with the Twitter API.

I wrote the backend logic in Haskell as I wanted to try a more “real-world” application of Haskell. For other supporting parts of the application, such as the database, I decided to keep it simple and to just use a SQLite db. Since I knew that the clients would be calling the backend at a slow fixed rate, SQLite would be more than enough to handle the load. For a general idea of how it works, you’ll want to refer to the diagram above. Specifically, it consists of two running Haskell Docker containers. One who’s job it is is to periodically call the Twitter API and look for posts with pictures that use a specific hashtag. When it finds new ones it adds them to the database. The webserver is also written in Haskell and will cycle through the posts in the local database. It displays them on the TV by running a webserver that serves a small frontend website (the TV can either access the website via a builtin browser app, or by having a Raspberry Pi connected to it via HDMI). The Javascript on the website will periodically call the webserver via a RESTful API and ask for a random image, which it will then transition to using CSS.

Although I was not able to finish the project in time due to the event itself requiring more planning than I anticipated, I had to go without the live posting digital photoframe. I completed the project later on in the hopes of using it for another event. Due to the restrictions on the Twitter API, this now won’t likely be used. I did have a lot of fun designing it, and I would consider using Haskell again for other similar projects. Since writing this post, Haskell has only matured and has added a lot of new quality of life improvements like quantified constraints and more user-friendly compiler error messages. I specifically like the sort of type-driven development that Haskell facilitates naturally.