DPS911 Blog #8: The joy of writing services
Tags: opensource
Published: 2021-03-11 18:15:25

With all the failures of them not working as intended along the way. Because the only easy day was yesterday! (And yes, I took a Call of Duty reference here, lots of fun with these games back in the day, not so much now).

This week's blog post is up much earlier than I normally write these. This is because I wanted to focus more on another assignment I have due on Friday. The topic of today: The Post Microservice!

This one was a big one. You can find the PR for this one [here](https://github.com/Seneca-CDOT/telescope/pull/1838). This PR took so many commits that I felt like I Was doing too much. This was important though, since it allowed me to iterate on a new service as much as possible while making mistakes. I never used Docker before working on this issue. I also never wrote unit tests for databases before too. I needed to write unit tests that interact with a mock redis so show that my service works. This took time, but I was able to finally get it working and I'm so happy with the results.

First off, I had to lay the foundation. This involved creating a folder, initializing the package.json, installing the dependencies I needed for my service, and creating the Dockerfile. David, thankfully, went over Docker so that alleviated alot of the worries. 

![Posts folder layout](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ngvkdreiccdng5zgb49u.png
)
The last piece was to add my service to the Docker-compose.yml file as well as add redis there. This piece would've been much harder if not for the image service being there already, allowing me to use it as a reference. I thought it was amazing here, that I could specify an environment tab, and docker would use it when the service runs. This allows me to specify process.env.POSTS_PORT, knowing that I can define it in the docker-compose.yml file and it would work without any problems. I also included the port and API url in all the env files to be safe as well. 

![Docker-compose layout](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/i5pu5no9hu0x6s6g0ia3.png)
I thought that would be it, but that ended up not being the case. Redis required that I put the container name there, so that my service can connect to redis properly. Without it, my posts service would always return an empty array. This was the bane of my existence for the first 2 days. After some time, this was the result:

![SUCCESS](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5wdfx7xfx4imhgrrs18s.png)

SUCCESS! Now to write the unit tests. This took me about a day, since I needed to learn about supertest, the dependency needed to get this done. I also needed to figure out how to mock redis so that I can insert fake data into the mock redis database. This was way easier than I made it, because the code to do this was already implemented last year when the original backend was made. There was code in place to use a mock database based on an env value. I simply had to include a jest.setup.js file, import the env settings and set MOCK_REDIS=1 and jest would use the mock redis instead of the real one when running my unit tests!

![Jest Setup Settings](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/aaoablqgtuyoa9gsyfm4.png)

![Redis file](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9e9fn0j8la75qd3qoc85.png)

The last problem here was my tests were taking too long, and thus failing because the network request took too long. Funny enough, this was due to a misunderstanding of how Promises worked. The addPost function returns a promise implicitly, so I didn't need to explicitly return one via Promise.resolve (Or Promise.all in the case of an array of posts). This was adding extra time to the network request that I simply did not need. Removing that solved all my issues!

![Relived!](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7ropc7w1f5emtxdw6ci4.gif)

It's not perfect. Currently, the e2e unit tests are failing CI. Assuming I get those fixed, this PR should be merged this week. This service is huge, as it's needed for many other services. It also needs to interface with other services that aren't available. For instance, the User Microservice that Chris is currently working on is where we're storing the posts, and the search service, currently stalled atm, will use elasticsearch to index posts. This service will absolutely need to be updated at some point, and I'm looking forward to doing that. I learned alot about Docker while working on this service, as well as redis and supertest. I might have to start using it alot more than I currently do.

Next time, a quiet week. With this big service in, I can turn my attention to other issues and PRs I wanted to work on. Until then, stay safe and see you guys next time!