Decoding JOT Token: A Mini Refactor Journey

TL;DR

• Identified missing method getDecodedJotToken during a merge.
• Dug into the codebase to figure out existing token handling methods.
• Discovered opportunities for refactoring token-related utilities.
• Transformed class methods into utility functions for better modularity.
• Planned a future refactor to reduce unnecessary dependencies.

Today, I wrestled with the merge of a rate-limiting feature. While navigating through hundreds of old alterations, I stumbled upon a method called getDecodedJotToken from the auth service that was strangely absent in my main codebase. The investigation led me to scour the Azure DevOps repository, pinpointing that this method had been part of other merged services and middleware but lacked a clear presence in the branch I was dealing with.

The quest for this function revealed it handled token extraction from the request.headers.authorization. I found a similar function within the extractUserInfoMiddleware and auth0.service.ts - a classic case of redundancy potentially caused by divergence over iterative merges.

Consequently, I formulated a plan to standardize this functionality. Despite contemplating an extensive refactor, I opted for a tactical adjustment. I decided on extracting the token manually—prepping a service function in the Auth service for getTokenFromRequest.

The realization struck that methods like getUserFromRequest and getUserFromToken were effectively operating as static utility functions instead of service-dependent operations, given their independence from external service calls. So, I designated them as utility functions, moving them into a shared module, thereby eliminating unwanted service dependencies. This move paved the way for a potential future ambitious refactor.

In executing the proposed updates, I encountered type compatibility hitches – particularly around TypeScript expecting specific custom properties that our JOT payloads weren’t inherently configured with. The revelation there was that using @ts-expect-error seemed most apt, succinctly marking known incompatibility while offering clear documentation for future eyes on the code.

Finally, I integrated these newly defined utility functions into my rate-limit middleware, bridging the gaps and thereby cleaning up dependencies. After aligning with the existing tests to validate the changes, I’m set for a smoother transition towards better-coded middleware.

This effort underscored the importance of examining your codebase holistically, knowing when utility over verboseness can provide clarity, and acknowledging when injecting dependencies is merely overcomplicating the problem.