After two days of mostly theoretical work, I felt like writing some code today. So I got my copy of the book Zero to Production and worked on the app's web server. As a result, the project is built with Rust now...
Subscribing to Events from GitHub
I wrote about what a minimum viable product for this project would look like in yesterday's post. One of the features that it needs is the ability to receive events from code hosting providers like GitHub. This feature has a simple and a complicated part.
The simple part is how platforms like GitHub deliver these events. Whenever something happens on GitHub, a webhook event is sent to any app that is subscribed to it. In the case of GitHub, this is done for (almost) literally everything. The webhook is sent to a pre-configured URL, which means the app needs a web server that can receive them.
The complicated part is figuring out what to do with the event. For this project, it means figuring out if any workflows need to run. This requires reading the user's configuration, which has been a topic of yesterday's post as well. Not much has changed since then, and how the configuration will look has yet to be decided.
So I decided to focus on the simple part that is clearly scoped for today.
Zero to Production
Last year, I bought a copy of the book Zero to Production by Luca Palmieri. It describes how to build a production-grade backend server with Rust. Back then I was working on a similar–albeit more limited–idea, and read through the first chapter as I was experimenting with the idea. I learned a lot from it, and always wanted to finish the book. As luck would have it, an update just dropped and I picked up the latest version and got started...
The book uses an iterative approach to introduce new topics. You start by setting up the web framework. Then you add integration tests, and after that a database. Each chapter builds on the previous one, and there is a strong focus on having something working after each step.
+2,532 −1
After working through the first four chapters of the book, I reached a good stopping point for today. I have a web server now that can receive webhooks from GitHub. The server verifies the authenticity of the webhooks by checking their cryptographic signature. Everything is tested with integration tests. And instrumentation is in place to monitor the server once it gets deployed. A lot of code was added today.
The next step is putting the events in a queue so that they can be processed in the background. This requires figuring out what data is later needed to process the events. And it needs setting up a background job system.
When I worked as a Ruby on Rails developer in the past, I always had great experiences with Sidekiq. It was so good that it became second nature to throw everything that didn't need to be synchronous into a queue and process it in the background. Luckily, Faktory exists as a "polyglot version of Sidekiq" (don't @ me).
My goal for tomorrow is to integrate Faktory into the app, and throw incoming webhooks into a queue. A background worker can then pick them up and figure out what to do for the event. This last step will require figuring out how to store configuration, but that's a problem for another day...
Day 3 was fun, let's continue tomorrow!
Top comments (0)