Midnight Shopping

Well, that was anti-climactic. The project is by no means done, but what I thought would be the hardest part and budgeted a whole week for turned out to be half a day for the actual logic and another to write effective tests. The store comparison function is running smoothly and came out to an easy to follow 167 lines of code; tests…

Upside is that the fussy bits for the comparison tests are being done as an update to the core NPM package and will let me sweep through all the other services and refactor to make sure that everything is actually using the same standards. As it sits prior to refactor, each part has individually hard coded mock responses for the other services and typos or API shifts might be hiding.

While I’ve been wrapping up the individual services, the database and its service have become available for integration. Remember those sweeping changes to standardize my tests? Also time to refactor out all the dummy logic and actually use the real database. I’m sure that will be a smooth process with no room for error or wasted time on stupid little errors.

Even though the project isn’t quite done, this is the final blog post. As such, now is my chance to look back and provide a retrospective. The biggest takeaway: I’m glad from a learning perspective that I chose to do a microservice architecture but boy howdy did I pay for it every step of the way. Just the redundant busywork of setting up each service and making sure its configuration is correct; eventually I learned the signs of each possible mistake but only after puzzling for hours.

Then there are the issues with GitHub. ‘Helpful’ articles laying out exactly how to configure a project to use private repositories which followed to the letter did nothing. Even when using a public repository, constantly needing to replace auto-generated package information so that it doesn’t try to access it as if it were private – which again refused to work under any situation. Upside to small, fractionated code is that I used only a percentage of my free system time; my front-end teammate used all of theirs up with a couple PR stages left to go.

The interwoven nature of microservices made testing a much larger portion than code logic; every test case needed one or more mocked responses to provide what would have come out of a call to another service. Fortunately this was an effective arm-twist to keep an up-to-date API document to refer back to when both writing routes and mocks for tests. Unfortunately as small changes piled up as needs were realized, the need for sweeping through everything as I mentioned earlier became clear.

Had I done a monolith, only the database would have needed to be mocked as all logic would have been internal to the program. I never would have needed to manage external dependencies as a single repository would have been consuming any code created. Only the routes needed by Gateway and Database would have been needed, saving on cross-reference between decoherent code.

That said…