In the last post I discussed about technology choices for Rappel. In this post I would like to discuss which features I prioritized for the first version and how.
I also realized that ideas have their own life-cycle and considering them as a subset of repos would be a really bad idea. I wanted to put them in a separate section. So the whole ideas board in the app went on the back-burner.
The priority was to build a system which can help manage a large number of repos on GitHub. I kept working diligently kept working towards that one goal.
It was quite difficult to wrap my head around the way GitHub OAuth apps work. The most complex part was figuring out how to create and use access tokens without hitting the rate limits when multiple users are using the system simultaneously. Turns out that OAuth apps can create a token per user.
I finally built a working prototype on my machine, but with so many repos (57 to be precise in my case), it was not much effective. It still needs an option to hide certain repos from the main board, search repos and filter repos based on various tags.
We had already stepped into 2021 by the time I was able to work out all the kinks in the basic prototype. I still had to check-in the code into Git and deploy it on DigitalOcean. I had to put these things on roadmap instead of feature list and move on to completing all other tasks. You might even notice that all of the posts were written and published in under 24 hours.
I started testing the domain name I had bought and realized that the default DNS management capabilities were not good enough. They did not even support CAA records 🤷🏻♂️. Thankfully, if we already own the domain name, DigitalOcean provides DNS management for free. The transfer took more than 24 hours and now any DNS changes propagate very quickly, plus I get a nice shiny interface to manage it, so a win-win!
Reflections
I had a choice: either to create a rock solid base version and defer nice to haves until after the hackathon OR implement all features at a "it just works level" without taking care of edge cases. I went with the former options and am quite happy with it.
DigitalOcean App Platform can have better support for mono-repos. I was not able to deploy from sub-folders. For example, I had my react app stored in a UI subfolder, but as there was a Dockerfile at the root of the repo I was not able to choose any other buildpack. Using multistage builds and storing the output of
npm run buildin the final stage would be an alternative, but the build time was too high for that.
Cover image: Photo by Alexis Fauvet on Unsplash
Top comments (1)
Liked the flow from motivation to final product!
Some comments have been hidden by the post's author - find out more