Posts

Reactive Architecture at the Code Level

Until now, we have considered reactive architectures at the system level. The implementation of such systems is based on message or event exchanges. Queues are typically used as the medium for propagating events or messages, while simple message buses are less common. We previously discussed the difference between a bus and a queue, and today we’ll talk about how reactive architecture is implemented at the code level. The core of implementing reactive architecture at the code level still revolves around messages, though the methods for message dissemination are not necessarily based on queues. Reactive patterns used at the code level typically implement a "data stream" approach, allowing for modular or micromodular implementations. This approach works especially well in stateless systems where the order of data processing is not important, though it can also be applied in scenarios where order matters (e.g., using the SAGA pattern). Today, we’ll focus on error-handling strate...

Books Every Developer Should Read (In My Opinion)

You know those moments when you want to chill but still feel productive? As a developer, those are the perfect times to pick up a book that sharpens your mind without making it feel like work. Over the years, I've come across some gems that aren’t just about cranking out code but about shaping the way you think, collaborate, and grow as a programmer. Here are a few books I’d recommend when you’ve got some free time and want to grow beyond the syntax. 1. The Pragmatic Programmer by Andrew Hunt and David Thomas This one’s a classic. If you haven’t read it yet, you’re missing out. It’s like the ultimate toolbox for practical thinking as a developer. They cover everything from version control to code hygiene in such a way that you feel like you’re learning from two seasoned mentors who get it . It’s more about mindset than language specifics, so it’s evergreen. Why read it? Because it makes you better at your craft without overwhelming you. Takeaway: Software craftsmanship is about ...

TypeScript: Why It's Needed and Why It's So Popular

Image
JavaScript code should work predictably in any situation. We could add many checks to our code, but that would make it bulky and hard to maintain. We could also add comments and hints, but they won’t protect us from incorrect code usage. In this situation, TypeScript comes to the rescue. Let’s explore why it's so useful for JavaScript developers. What is TypeScript? TypeScript is a strongly typed programming language based on JavaScript. It consists of three main parts: Language syntax, Compiler, Editor service. TypeScript syntax allows developers to express solutions elegantly in .ts or .tsx files. It’s an evolution of JavaScript’s syntax, meaning any JS program is syntactically valid in TypeScript. The tsc compiler helps catch many defects before deployment. It transforms TypeScript source code into JavaScript and analyzes the program to identify potential issues. TypeScript can generate .js files for any version of JavaScript, starting from ES3. Deve...

Designing REST Applications

Image
One reason web applications are popular is their ability to scale the load and distribute responsibilities among system components. Client-server architecture is used to manage the complexity of web applications, allowing not only to distribute responsibilities but also to significantly complicate the server side by making it multi-layered with many intermediate components. Since the bulk of a web application is not the business logic but the infrastructure, the task arises of managing the correct transfer of the business logic state. The REST architectural style was developed to take full advantage of distributed systems, and its adaptation to web applications became known as RESTful. When we talk about REST applications, we usually mean RESTful applications. In this stream, we will consider the main architectural aspects related to building such applications. The proposed principles and rules will allow you to build and expand web applications without violating REST principles and wi...

API design

  An API is a contract that describes the interaction between two or more systems, both from the perspective of external and internal use. It is the most efficient way to manage the complexity of the system being implemented, establish architectural boundaries, isolate data, and implement security requirements. Designing a good API involves several key stages, which I will discuss in this article. Software development is generally data-driven. Most APIs are built around data sources (usually databases) and have a resource-oriented nature. There are exceptions in the form of APIs that manage system operations, which are typically well-standardized and reused across projects. These system-oriented APIs address tasks such as resource management and access control. API from a State Perspective: Stateful (server maintains state) Stateless (no server-side state) API Work Styles: Remote Procedure Call (RPC) : One of the most widely used styles for building APIs. It is implemented throug...

Technical debt and methods for assessing it

Technical Debt Technical debt is one of the primary issues hindering the steady and dynamic development of a project. Many teams do not assess their technical debt and struggle to answer what technical debt is and how to measure it. In this stream, we will look at a simple point-based assessment method, which involves a set of binary assessments (one assessment equals one point). In this stream, we will define technical debt as a set of accumulated problems within a project that have a technical nature (code, infrastructure, architecture), or those that affect technical decisions (management). Since different people in an organization are responsible for different areas related to development, it is better to divide the assessment of technical debt according to these areas of responsibility and address the issues within each area separately. Management (technical leads, managers, consultants, etc.); Project infrastructure (DevOps, architects); Code infrastructure (architects); Codeb...

General Approach to Breaking Down a Monolith into Components

The main topic of this discussion is "component-based decomposition." Like any form of decomposition, this is only part of the process of building application architecture, to reduce the coupling between components. In some cases, this requires changing the component structure of the application. Monoliths are often highly coupled, component-based applications, meaning that a component itself is not necessarily an indicator of good decomposition. To reduce coupling, two approaches are commonly used: "extracting components" and "branching (duplicating) components." In the first case, we gradually reduce coupling by selectively extracting components from the entire application. In the second case, the entire monolith is copied, and unnecessary elements are removed. Moving away from monolithic architecture requires a well-thought-out decomposition into components, and we will explore the following algorithm: Codebase optimization Determining the level of coup...