Containerization

[Awbmilne]

It would be incredibly useful for self-hosting if this application was containerized.

Based on your existing Github Workflow, I can tell that this would require you to re-construct some of your infrastructure. But, it would provide amazing deploy ease for others and potentially your future self.

I am likely to take a crack at containerizing this application over the Holiday break (Dec 2022-Jan 2023). Let me know what your feelings are on this and If you have any concerns.

My ultimate goal is to be able to run this bot from Docker on a Raspberry Pi using Docker-Compose.

[Kav-K]

Sounds good, but what kind of infrastructure reconstruction are you thinking of? Currently, the way that redis-data is stored is pretty crude, redis data is stored in a 1:1 mapping of redis db to server, are you thinking that we just keep this functionality but have it be containerized so that functionality can be easily portable across anyone who wants to run their own instance? For example, I'm running my main instance for the UWHelperBot that powers the various university of waterloo servers, if you containerize the application, is the goal to theoretically for someone else to be able to just docker-compose the image and be able to run a main instance like me?

[Awbmilne]

Overall, I think a more robust solution would separate the database and the bot applications. It might also be a good idea to use a more robust SQL style database.

The vision in my head is to containerize the application such that it can be easily deployed on its own, creating a new instance for someones own server. The primary reasoning behind hosting one's own instance would be the data privacy. While I'm sure you are taking reasonable measures for privacy and security, there is nothing like having control of your own data.

[Kav-K]

Hmm, the only gripe I have with using SQL is the latency, the reason we use Redis is because it's incredibly fast, and so much faster than SQL, especially in the context of a Discord bot that needs to have real-time responses and very quick data retrieval, not to mention quick data retrieval across database instances (but I guess that can be changed with schema design), do you think SQL would be adequate?

[Awbmilne]

After a little more research (i'm not super familiar with Redis), it seems like Redis is a better and easier solution than SQL.
My initial reaction was that a database stored in memory is problematic for size reasons, but when you are only ever talking about the number of students using discord at Waterloo, you would likely never surpass a gigabyte of stored verification content, so database size is of limited concern. Whilst I don't think SQL would be so slow as to cause issues, Redis is probably a better solution overall.