#3: Implementing a whole microservice from ground up

published on

This was my final project for Taskcluster before I got busy with school work. Coincidentally, it was also my biggest contribution yet involving more than 1500 modified lines, 4 PRs and 100s of comments worth discussion and constructive criticism. This whole project took me well around a month to implement and the folks over at Taskcluster were nice enough to guide me throughout.

As mentioned in my previous posts, Taskcluster is used for continuous integration and task execution. It has a notification service that notifies clients whenever their submitted task is completed. This service used to have a denylist feature to simply blacklist certain addresses from recieving notifications based on their past behaviour. The issue was that this denylist feature had no UI whatsoever and was only implemented as a config file.

This project involved implementing the UI for the notification denylist. Since it was only present in the form of a config file, there was no database of the denylisted addresses as well as no API endpoints to add, delete or query the denylist. Further, the notification service simply read the denylisted addresses from the config file and there was no support to do so through a DB.

Although this time the changes were isolated to the notification service, I had to implement everything from scratch. Some of the tasks involved were:-

  • Creating a DB

    The blacklisted addresses needed to be stored in a DB in order to be used in a consistent manner. AzureDB was used to achieve this and consequently, I learned a great deal about NoSQL datastores which I had no prior experience working with.

  • Hooking up the DB

    Next Up, I had to link the DB instance with the notification service. Taskcluster uses a very sophisticated system for setting up services and injecting dependencies. It’s done using their own library, taskcluster-api, and it took me significant effort and some guidance to get the whole process down.

  • Adding CRUD endpoints to the DB

    Once the DB was set up and working, I had to add creation, updation and deletion endpoints that would be called by the GraphQL server in order to access and modify the denylist database.

  • Modifying existing API endpoints

    The existing notification API had to be modified to restrict sending notifications to addresses in the database. The addresses that were initially passed in the config file had to now be added to the denylist database.

  • Writing tests

    Again, several new unit tests had to be written to ensure proper working of the new API endpoints as well as the modified ones.

  • Modifying the graphQL server

    Taskcluster’s web-server is based on GraphQL rather than REST. As I had no experience with GraphQL, I had to learn it from scratch and write new data types as well as GraphQL reslovers to accomodate the new API endpoints.

  • Finally, implementing the UI

    This was the final task of the project. A whole UI had to be implemented for the denylist. Since the notification service had no UI till now, the whole thing had to be implemented from scratch. This also involved writing new GraphQL queries to query the backend to edit the denylist.

So with that I was finally able to understand and implement a good chunk of a whole microservice in taskcluster.

When I intitially started out fixing small typos, I had no idea I would get a chance to work on so many interesting projects and learn such a great deal about software development in general. To top it off, my contributions didn’t go unnoticed and I was officially made a collaborator of Taskcluster and granted push rights to the repository. I also had my picture and name added to the project front page on github which in itself is a great achievement for me.

I am linking to the relevant PRs and forums below. All the discussion and code related to this project can be found in these links:-