If you've been following the GitHub Twitch channel, you'll notice myself and Bdougie have been building a Twitch chat bot.
On Part 1 of our tutorial, we showed our audience how to use webhooks to have the GitHub API connect to Twitch. Our chatbot listened to GitHub events and responded accordingly.
Part 2 had us coding the CSS, cleaning up the code, changing the gifs, and working through some of the suggestions from the community.
In both Parts 1 and 2, we only had our chatbot deployed to local host. Now, in Part 3, we deploy our chatbot to the cloud. This ensures we have a server running that we can then link directly to OBS for output.
When it comes to webservers, there are a lot of options. Here's two we went with and why.
Deploying your code to the cloud
As developers, we are spoilt for choice when it comes to deploying code in the cloud. In Bdougie's readme file, there's a list of some possible cloud providers.
This is a service for GitHub and twitch interaction
This is a service for github and twitch to interact with each other. The use case for this git-twitch interaction between Twitch and GitHub through webhooks. If you are new to Twitch Chat interactions, you can check out my original chatbot, the beybot. In the README you will find further explanation on how Twitch interactions work.
🍴Setup for local development
1. Fork this repo (optional, open a Codespace)
The fastest way to get started is by forking this repo. PRs are welcomed if you find anything missing or unclear.
smee.io is a Webhook payload delivery service. It receives payloads then sends them to your locally (development) running application. Smee is not meant to be used in production.
In your newly forked repo, create a webhook from the repo settings that points…
We decided to deploy Git Twitch on two different cloud provides. The first is Digital Ocean. The advantage of Digital Ocean is that it's fairly easy to setup. You can connect your GitHub repo direct to your account. The biggest win Digital Ocean is however is the service stays running. Even when you're offline, your chatbot will still be listening to GitHub events ready to use on stream when you go live. The main disadvantage of Digital Ocean is the cost.
Our second deployment went to Replit. The big advantage of Replit here is the cost - it's free. No need to worry about how much you'll use the service or being overcharged. The main disadvantage is the server is not constantly running. If you deploy your chatbot (or any other code) to Replit, you'll need to 'wake up' the server every time you want to use it.
This means that we'd need to push an event every time we want the chatbot to be active. In our case, this would mean staring the repo before we went live on stream. Once the server is awake, the service will only continue to run for approximately 30 minutes. This is no problem if you're streaming and have viewers constantly staring the repo - or creating events that your bot is listening to. An alternative would be to create a script to wake up your server when you are about to go live on stream.
By contrast, Digital Ocean does not require you to constantly be aware of your server's status. You also don't have to worry too much about being overcharged as there is a maximum server expenditure per month. For many users however, the Replit server might be just enough to have some interaction in your chat every week or so.
There are also other webservers to deploy your cloud to. These include Heroku, Azure, and many more.
Are you planning on using our Twitch chatbot? Which server is your go to choice? Let us know your favourites, and remember, you can clone, fork, or contribute to Git Twitch. We can't wait to see more Twitch streams making use of notifications for GitHub-specific events.
Don't forget to tune into our next Open Source Friday live coding stream. Join our GitHub Virtual Meetup Group to stay up to date on all our GitHub live streams.
Michelle Duke
00:59
