Webdev Blog by SB

In complex systems built on a microservice architecture, resilience isn’t just a nice-to-have, it’s essential. One common approach to testing system robustness is Chaos Engineering, where you intentionally introduce failures to see how well your system recovers. Netflix’s Chaos Monkey is a famous example: it randomly kills services in production to ensure systems can handle failure gracefully. While that level of chaos might be overkill for most teams (especially outside of production), the core idea, testing your system’s response to failure, is invaluable. Inspired by this, we recently added a small but effective piece of middleware to one of our services: a manually triggered route-level failure tool that acts like a “baby Chaos Monkey.” Our infrastructure is composed of many interdependent microservices. Even small changes can have surprising ripple effects, especially when services rely on each other in subtle ways. This middleware gives us a lightweight, controlled way to simul...

Designing robust and well-documented web APIs is a crucial part of modern software development. One of the most widely adopted standards for describing RESTful APIs is OpenAPI. It provides a machine-readable format—typically written in JSON or YAML—that defines the structure, endpoints, request/response formats, and other aspects of an API. This schema becomes a single source of truth, powering everything from interactive documentation to client libraries and server stubs. However, writing and maintaining OpenAPI specifications by hand can quickly become a chore. The syntax is verbose, and small mistakes in the structure can lead to frustrating bugs or inconsistencies across different parts of the system. This is where TypeSpec comes in. TypeSpec is a language developed by Microsoft for describing APIs in a more developer-friendly way. Instead of wrestling with raw OpenAPI YAML, you write a TypeSpec file that feels more like TypeScript: concise, expressive, and modular. From this s...

Our App was created in 2017. It is a React application written in TypeScript. At the time, TypeScript was gaining popularity, but strict type safety wasn’t a major concern for most teams. Our knowledge of TypeScript was limited, and the primary goal was to use it for basic type annotations rather than enforcing a fully type-safe codebase. As a result, TypeScript’s strict mode was not enabled. This meant that the codebase lacked certain safeguards, such as strict null checks, no implicit any, and more rigorous type inferences. Over time, as the project grew in size and complexity, the lack of strict typing introduced subtle bugs and made refactoring riskier. Fast forward to today, the project has grown significantly. It now consists of approximately 2270 TypeScript files, making it a massive undertaking to migrate to strict mode. However, the benefits of enabling strict mode—better type safety, easier maintenance, and fewer runtime errors—outweighed the challenges. This blog post docu...