DEV Community: Ewerson Vieira Nascimento

Resilience Strategies for Microservices

Ewerson Vieira Nascimento — Mon, 09 Sep 2024 00:04:28 +0000

Resilience in microservices starts with the acknowledgment that failures are inevitable, and therefore, systems must be designed to adapt when these failures occur. This involves implementing a group of strategies aimed at minimizing the risks of data loss and ensuring the continuity of important business transactions. Techniques such as data replication, distributed transaction management, and real-time monitoring help safeguard the integrity and availability of critical services. By anticipating failures and preparing for them, systems can maintain functionality and performance even under adverse conditions.

The goal of this article is to list some concepts and strategies to address resilience for microservices as there are a lot of actions we can take to ensure resilience in our applications.

The starting point for resilience in this context is the concept of protecting and being protected. This means each service should be capable of self-preservation, maintaining consistent response times regardless of external issues, and avoid making requests to known failing systems, using mechanisms like circuit breakers. Not only that, but microservices should also bypass slow systems, which can be more harmful than complete failures.

Health Check

Health checks are vital for maintaining resilience in microservices. They should assess all system dependencies to provide a comprehensive status of the system’s health. An unhealthy system can often recover, or self-heal, if it stops receiving traffic temporarily. There are two types of health checks: passive and active. In a passive health check, the system becomes aware of its health status only upon receiving a request, such as when a service fails to respond correctly and triggers an alert. Active health checks involve the system continuously monitoring its own health or being monitored by other systems. For example, in an e-commerce platform, an active health check might involve the catalog service periodically checking the database connection and the API gateway checking the status of all microservices it routes traffic to, ensuring any issues are detected and addressed proactively.

Rate Limit

Rate limiting is a technique used for protecting a system by ensuring it only handles the load it was designed to support. By controlling the number of requests a service can handle within a given timeframe, rate limiting prevents system overloads and maintains performance. It can be customized based on client type, allowing different rate limits for various users or services. In an API-driven platform for instance, regular users might be allowed 100 requests per minute, while premium users are allowed 1,000 requests per minute. This ensures the system remains stable and responsive, even under high demand, by prioritizing and managing traffic according to the designed capacity and client preferences.

Circuit Breaker

The circuit breaker pattern is essential for enhancing system resilience by managing requests to potentially failing services. It functions by denying requests when necessary to prevent overload and cascading failures.

In the closed state, it allows requests to proceed normally. If a service failure is detected, the circuit breaker transitions to the open state, blocking all requests to the failing service to prevent further issues. After a specified time, it moves to the half-open state, permitting a limited number of requests to test if the service has recovered. We could use the circuit breaker pattern in a payment processing system: if the payment gateway becomes unresponsive, the circuit breaker opens, stopping all payment attempts. After a cooldown period, it enters the half-open state, allowing a few transactions to check if the gateway is back to normal before fully reopening.

API Gateway

An API Gateway is a component of a microservices architecture that acts as an entry point that prevents inappropriate requests from reaching the system. It enforces policies for rate limiting, health checks, and other crucial functions, thereby managing traffic and protecting services.

In an e-commerce platform, an API Gateway could limit the number of requests per user, check the health of backend services before routing requests, and block malicious traffic, ensuring the system remains stable and efficient.
API Gateway also helps avoid the “Death Star” scenario (where a vast number of microservices lead to complexity and potential failures) by having requests going through private API Gateways instead of direct calls to microservices.

Service Mesh

A Service Mesh is a dedicated infrastructure layer that controls network traffic between microservices via proxies, offloading responsibilities from individual services.

It avoids the need for each service to implement its own protection mechanisms. Key features include mutual TLS (mTLS) for secure communication and policies for circuit breakers, retries, timeouts, and fault injection. In a financial services application, for example, a Service Mesh can manage secure connections between services, enforce retry policies for transient errors, and implement circuit breakers to prevent cascading failures, all without altering the services themselves, thereby enhancing overall resilience and security.

Working Asynchronously

Working asynchronously involves sending information to a message broker, ensuring that the message is received, and allowing interested systems to consume it at their own pace. This approach helps handle a higher volume of requests and reduces the risk of data loss if a server is down, as messages are stored and processed later.
In an e-commerce platform, when a user places an order, the order details could be sent to a message broker like Kafka. This allows the order processing system to handle the request asynchronously, ensuring that even if the order processing service is temporarily down, the message will be stored and processed once the service is back online. Developers must have good knowledge of the message broker or streaming system to effectively implement and manage asynchronous workflows.

Retry

Retry mechanisms are used to handle transient failures by attempting a request again after an initial failure. Using exponential backoff with jitter, the system increases the wait time between retries and adds randomness to prevent simultaneous retries across multiple systems.

Example: in a payment processing system, if a transaction request fails due to a temporary issue, the system retries the request with increasing delays (e.g., 1s, 2s, 4s) and introduces random delays to avoid all retries happening simultaneously. This approach improves the likelihood of success while preventing overload and collisions in the system.

Delivery Guarantees

Delivery guarantees ensure that messages are reliably delivered and processed in a messaging system. In Kafka, delivery guarantees can be set to 0, 1, or -1:

0: No acknowledgment is required from the broker. This is the fastest but least reliable. An Uber app might send user/driver location updates with 0 acknowledgment to minimize latency, accepting that some updates might be lost.
1: The message is acknowledged by the leader broker, ensuring it is written to at least one replica. This strikes a balance between speed and reliability.
-1: The message must be acknowledged by all in-sync replicas, providing the highest reliability but with increased latency.

Choosing the appropriate guarantee depends on the required trade-off between reliability and performance for different use cases.

Complex Situations

In complex situations where a message broker goes down, several challenges come up, such as potential message loss and whether your system will remain operational. To ensure resilience, it’s crucial to implement strategies like:

Durable Storage: Ensure the message broker uses durable storage to prevent data loss. Kafka stores messages on disk and replicates them across multiple brokers to avoid data loss.
Retry Mechanisms: Implement retry logic to handle temporary failures and reconnect to the broker once it’s back online.
Fallback Strategies: Design the system to switch to a fallback mechanism or queue messages temporarily if the broker is unavailable.

In an order processing system, if the message broker fails, messages might be temporarily stored in a local queue and retried once the broker is operational again, ensuring the system can recover without complete downtime.

Transactional Outbox

A transactional outbox ensures reliable message delivery by saving messages to a database table before sending them to the message broker. If the broker is down, the messages are stored temporarily in this table and are sent to the broker once it becomes available again. An usage of this concept could be in an e-commerce system: when an order is placed, the order details are saved to a transactional outbox table in the database. If the message broker is temporarily unavailable, the system stores the order details in the outbox table. When the broker is back online, a process reads from this table and sends the pending messages to the broker, ensuring no data is lost and the system remains resilient.

Receipt Guarantees

Receipt guarantees certify that once a message is processed, the system commits to acknowledging it so the message broker can discard it, preventing reprocessing. This is achieved by having the system send a confirmation to the broker after successfully handling the message. In a payment system context, this acknowledgment could be sent to a message broker after a payment message is successfully processed.
To optimize performance and reduce downtime, it’s essential to align the prefetch settings with the expected volume, determined through stress tests and hardware checks.

Idempotence and Fallback Policies

Idempotence guarantees that processing a message multiple times does not produce different results, which is crucial for avoiding issues with information duplicity. In banking systems, if a deposit message is received twice due to a retry, idempotence guarantees that the deposit is only applied once, preventing duplicate entries.

Fallback policies handle scenarios where the primary operation fails. So, in this context, if a deposit transaction fails to process due to a temporary issue, a fallback policy might involve retrying the operation or applying a compensating action to correct the error. This ensures that the system remains reliable and can recover from failures without affecting data consistency.

Observability

Observability tools are used for monitoring and understanding the behavior of microservices systems. It involves:

Application Performance Monitoring (APM): Tracks overall application performance, identifying bottlenecks and issues. It can highlight slow response times in your system.
Distributed Tracing: Allows tracking of requests as they travel through various microservices. For instance, distributed tracing can show the journey of a user order from placement to payment and shipping.
Custom Metrics: Provides insights into specific aspects of system performance, like the number of successful transactions or error rates.
Custom Spans: Each span represents a step in the system’s processing, helping to pinpoint where delays or failures occur. A span could track the time taken to validate a user’s credentials.
OpenTelemetry: A standard framework for collecting and exporting observability data, including traces and metrics. It helps integrate various observability tools, providing a unified view of the system’s performance.

Using these tools can give you deep insights into your microservices’ behavior, ensuring that issues are quickly identified and resolved.

Conclusion

When building microservices, thinking about resilience from the outset is crucial. It ensures that your system can withstand and recover from failures, maintaining continuity and reliability. The techniques discussed in this article — such as health checks, rate limiting, circuit breakers, API Gateways, and Service Meshes — provide a comprehensive toolkit for enhancing resilience. Each method addresses different aspects of system stability and performance, from managing traffic and preventing overloads to ensuring secure communication and reliable message delivery. The key point is to always have a proactive approach to resilience to thrive in unpredictable environments.

Are Microservices the Right Choice for You?

Ewerson Vieira Nascimento — Mon, 09 Sep 2024 00:03:04 +0000

Microservices have emerged as a transformative architectural style. As I delve deeper into software architecture, I find it essential to share insights on microservices, drawing from both study and practical experience. This article aims to provide a comprehensive understanding of microservices, their advantages, and when they are the right choice for your projects.

Basics of Microservices

At its core, a microservice is a small, independent service with a well-defined objective. These services collectively form an ecosystem, working together to achieve a larger goal while maintaining autonomy. The independence of microservices allows them to be developed, deployed, and scaled independently.

Microservices vs. Monoliths

The debate between microservices and monolithic architectures is ongoing, and understanding the differences is crucial.

Separated Contexts: Microservices are designed around specific business capabilities, allowing for more focused and modular development. In contrast, monoliths bundle everything into a single codebase.
Technological Flexibility: Each microservice can use the technology stack best suited for its purpose, unlike monoliths, which are often constrained to a single technology stack.
Risk Management: Deploying microservices can be less risky since changes to one service don’t necessarily impact others. However, deploying a monolithic application means any change could potentially affect the entire system.
Team Organization: Microservices enable teams to be organized around individual services, promoting ownership and accountability. Monolithic teams often have to navigate a more complex codebase, making it harder to isolate responsibilities.
Initial Complexity: Starting with microservices can be complex due to the need for clear boundaries and infrastructure for inter-service communication. Monoliths, on the other hand, can be simpler to kick off but might become unwieldy as they grow.

When to Use Microservices

Microservices shine in certain scenarios:

Scaling Teams: When multiple teams need to work on different parts of a system concurrently.
Well-defined Contexts: When business areas or contexts are clearly delineated.
Mature Delivery Processes: Organizations with established CI/CD pipelines and testing frameworks.
Technical Maturity: Teams with the expertise to manage the complexities of distributed systems.
Selective Scalability: When only specific parts of the system require scaling.
Technological Diversity: When parts of the system need different technologies for optimal performance.

When to Use Monoliths

Monolithic architectures are still relevant and advantageous in certain cases:

Proof of Concept (POC): Quick iterations and validations without the overhead of managing multiple services.
New Projects: When the domain is not fully understood, and rapid changes are expected.
Simplified Governance: Easier to manage and enforce consistency in technology and practices.
Ease of Hiring and Training: Developers can be onboarded more quickly with a unified codebase.
Shared Libraries: Easier to share and maintain common libraries within a single codebase.

You can check more about this subject in this other article I wrote about Monoliths.

Migrating from Monoliths to Microservices

Transitioning from a monolithic architecture to microservices requires careful planning:

Separate Contexts (DDD): Use Domain-Driven Design to identify and separate contexts.
Avoid Excessive Granularity: Ensure services are sufficiently large to manage independently but not too granular.
Dependency Management: Avoid creating a distributed monolith with tight coupling between services.
Database Migration: Plan how to migrate databases to ensure data consistency and integrity.
Use Events: Leverage event-driven architectures for better decoupling.
Data Duplication: Don’t shy away from duplicating data when necessary.
Eventual Consistency: Embrace eventual consistency rather than immediate consistency.
Mature CI/CD: Ensure strong CI/CD pipelines, testing, and environment management.
Start Small: Begin with less critical domains using the Strangler Pattern to incrementally replace parts of the monolith.

Characteristics of Microservices

Successful microservices exhibit several key characteristics:

Componentization via Services: Each service is a component responsible for a specific functionality.
Business-Aligned: Services are organized around business capabilities and managed by cross-functional teams.
Product Mindset: Treat each service as a product, focusing on continuous improvement.
Smart Endpoints, Dumb Pipes: Services communicate through simple, direct messages without intermediaries.
Decentralized Governance: Teams choose the best technologies and establish clear communication contracts.
Decentralized Data Management: Multiple databases are allowed, with data duplication managed thoughtfully.
Infrastructure Automation: Automate infrastructure management to handle the complexity of distributed systems.
Design for Failure: Build resilient systems that can handle failures gracefully.
Evolutionary Design: Design services to be replaceable and upgradable independently.

If you want a more in-depth look at these topics, you can check it out here.

Conclusion

Microservices offer a robust approach to building scalable and maintainable systems, especially for complex and evolving business needs. However, they also introduce complexity that requires technical maturity and careful planning. Understanding when and how to leverage microservices versus monolithic architectures can make a significant difference in the success of your projects.

I hope this summary about microservices provides some valuable insights and helps you in making informed architectural decisions. In the next article I’ll write about resilience in microservices.

Are Microservices the Right Choice for You?

Ewerson Vieira Nascimento — Mon, 09 Sep 2024 00:03:04 +0000

Basics of Microservices

Microservices vs. Monoliths

The debate between microservices and monolithic architectures is ongoing, and understanding the differences is crucial.

Separated Contexts: Microservices are designed around specific business capabilities, allowing for more focused and modular development. In contrast, monoliths bundle everything into a single codebase.
Technological Flexibility: Each microservice can use the technology stack best suited for its purpose, unlike monoliths, which are often constrained to a single technology stack.
Risk Management: Deploying microservices can be less risky since changes to one service don’t necessarily impact others. However, deploying a monolithic application means any change could potentially affect the entire system.
Team Organization: Microservices enable teams to be organized around individual services, promoting ownership and accountability. Monolithic teams often have to navigate a more complex codebase, making it harder to isolate responsibilities.
Initial Complexity: Starting with microservices can be complex due to the need for clear boundaries and infrastructure for inter-service communication. Monoliths, on the other hand, can be simpler to kick off but might become unwieldy as they grow.

When to Use Microservices

Microservices shine in certain scenarios:

Scaling Teams: When multiple teams need to work on different parts of a system concurrently.
Well-defined Contexts: When business areas or contexts are clearly delineated.
Mature Delivery Processes: Organizations with established CI/CD pipelines and testing frameworks.
Technical Maturity: Teams with the expertise to manage the complexities of distributed systems.
Selective Scalability: When only specific parts of the system require scaling.
Technological Diversity: When parts of the system need different technologies for optimal performance.

When to Use Monoliths

Monolithic architectures are still relevant and advantageous in certain cases:

Proof of Concept (POC): Quick iterations and validations without the overhead of managing multiple services.
New Projects: When the domain is not fully understood, and rapid changes are expected.
Simplified Governance: Easier to manage and enforce consistency in technology and practices.
Ease of Hiring and Training: Developers can be onboarded more quickly with a unified codebase.
Shared Libraries: Easier to share and maintain common libraries within a single codebase.

You can check more about this subject in this other article I wrote about Monoliths.

Migrating from Monoliths to Microservices

Transitioning from a monolithic architecture to microservices requires careful planning:

Separate Contexts (DDD): Use Domain-Driven Design to identify and separate contexts.
Avoid Excessive Granularity: Ensure services are sufficiently large to manage independently but not too granular.
Dependency Management: Avoid creating a distributed monolith with tight coupling between services.
Database Migration: Plan how to migrate databases to ensure data consistency and integrity.
Use Events: Leverage event-driven architectures for better decoupling.
Data Duplication: Don’t shy away from duplicating data when necessary.
Eventual Consistency: Embrace eventual consistency rather than immediate consistency.
Mature CI/CD: Ensure strong CI/CD pipelines, testing, and environment management.
Start Small: Begin with less critical domains using the Strangler Pattern to incrementally replace parts of the monolith.

Characteristics of Microservices

Successful microservices exhibit several key characteristics:

Componentization via Services: Each service is a component responsible for a specific functionality.
Business-Aligned: Services are organized around business capabilities and managed by cross-functional teams.
Product Mindset: Treat each service as a product, focusing on continuous improvement.
Smart Endpoints, Dumb Pipes: Services communicate through simple, direct messages without intermediaries.
Decentralized Governance: Teams choose the best technologies and establish clear communication contracts.
Decentralized Data Management: Multiple databases are allowed, with data duplication managed thoughtfully.
Infrastructure Automation: Automate infrastructure management to handle the complexity of distributed systems.
Design for Failure: Build resilient systems that can handle failures gracefully.
Evolutionary Design: Design services to be replaceable and upgradable independently.

If you want a more in-depth look at these topics, you can check it out here.

Conclusion

I hope this summary about microservices provides some valuable insights and helps you in making informed architectural decisions. In the next article I’ll write about resilience in microservices.

Building Reliable Software: Testing Concepts and Techniques

Ewerson Vieira Nascimento — Sun, 08 Sep 2024 23:59:58 +0000

Ensuring code quality and reliability is a must! This often means adopting various testing methodologies and tools to validate that the software performs as expected. As developers, especially those new to the field, it is crucial to understand concepts like Unit Tests, Mocks, End-to-End Testing, Test Driven Development (TDD), and some other concepts that we’ll discuss further in this article. Each of these plays a significant role in the testing ecosystem, helping teams create robust, maintainable, and reliable applications. The goal is to clarify some testing techniques and concepts, providing explanations and practical examples so one can understand a bit more about software testing, especially in the JavaScript ecosystem.

Unit Tests

Unit tests are a fundamental aspect of software testing that focus on verifying the functionality of individual components or units of code, typically functions or methods. These tests aim to ensure that each unit of the code performs as expected in isolation, without relying on external systems or dependencies.

What Are Unit Tests?

Granular Testing: Unit tests target the smallest parts of an application, such as individual functions or methods.
Isolation: They isolate the code under test from other parts of the application and external dependencies.
Automated: Unit tests are typically automated, allowing them to be run frequently during development.

Why Use Unit Tests?

Early Bug Detection: They catch bugs early in the development process, making them easier and cheaper to fix.
Code Quality: Unit tests promote better code quality by ensuring that each unit of code works correctly.
Refactoring Safety: They provide a safety net when refactoring code, ensuring that changes do not introduce new bugs.
Documentation: Unit tests serve as a form of documentation, showing how individual units are supposed to function.

Real-World Scenario

Consider a scenario where you have a function that calculates the factorial of a number. You want to ensure this function works correctly for various inputs, including edge cases.

Example Code

Here’s a simple implementation of a factorial function and its corresponding unit tests using Jest:

// factorial.js
function factorial(n) {
    if (n < 0) throw new Error('Negative input is not allowed');
    if (n === 0) return 1;
    return n * factorial(n - 1);
}

module.exports = factorial;

Unit Tests

    // factorial.test.js
const factorial = require('./factorial');

describe('Factorial Function', () => {
    it('should return 1 for input 0', () => {
        expect(factorial(0)).toBe(1);
    });

    it('should return 1 for input 1', () => {
        expect(factorial(1)).toBe(1);
    });

    it('should return 120 for input 5', () => {
        expect(factorial(5)).toBe(120);
    });

    it('should throw an error for negative input', () => {
        expect(() => factorial(-1)).toThrow('Negative input is not allowed');
    });
});

Explanation

Function Implementation: The factorial function calculates the factorial of a number recursively, with error handling for negative inputs.
Test Suite: Using Jest, we define a test suite (describe) and multiple test cases (it) for different inputs.
Test Cases:
• The first test checks if the function returns 1 for input 0.
• The second test checks if the function returns 1 for input 1.
• The third test checks if the function returns 120 for input 5.
• The fourth test checks if the function throws an error for negative input.

Benefits of Unit Tests

Speed: Unit tests are fast to run because they test small units of code in isolation.
Reliability: They provide consistent results and help maintain high reliability in codebases.
Regression Prevention: By running unit tests frequently, developers can catch regressions early in the development cycle.

Best Practices for Writing Unit Tests

Keep Tests Small and Focused: Each test should verify one specific behavior or scenario.
Use Descriptive Names: Test names should clearly describe what they are testing.
Avoid External Dependencies: Mock or stub external dependencies to keep tests isolated and fast.
Run Tests Frequently: Integrate unit tests into your continuous integration pipeline to run them on every code change.
Cover Edge Cases: Ensure tests cover edge cases, including error conditions and boundary values.

Integrating unit tests into your development workflow can significantly enhance the reliability and maintainability of your software as they are a critical part of a comprehensive testing strategy.

Mocks

Mocks are an essential concept in software testing, particularly when dealing with dependencies that make testing difficult. To put it simply, mocks are objects that simulate the behavior of real objects in a controlled way. This allows you to test your code in isolation by replacing real dependencies with mock ones.

Why Use Mocks?

Isolation: Test your code independently from external systems or services (like databases, APIs, etc.).
Speed: Avoid delays from network calls or database operations, making tests faster.
Control: Simulate various scenarios, including edge cases and error conditions, that might be hard to reproduce with real dependencies.
Reliability: Ensure tests run consistently without being affected by the external environment.

Real-World Scenario

Imagine you have a UserService that needs to create new users by saving their information to a database. During testing, you don't want to actually perform database operations for several reasons (speed, cost, data integrity). Instead, you use a mock to simulate the database interaction. By using a mock, you can ensure that the saveUser method is called correctly when createUser is executed.

Let's explore this scenario using Node.js with a testing setup involving Jest to mock the Database class and verify the interactions in UserService.

Example Code

UserService.ts

export class UserService {
    private db;

    constructor(db) {
        this.db = db;
    }

    getUser(id: string) {
        return this.db.findUserById(id);
    }

    createUser(user) {
        this.db.saveUser(user);
    }
}

Database.ts

export class Database {
    findUserById(id: string) {
        // Simulate database lookup
        return { id, name: "John Doe" };
    }

    saveUser(user) {
        // Simulate saving user to the database
    }
}

Test with Mock

import { UserService } from './UserService';
import { Database } from './Database';

jest.mock('./Database');

describe('UserService - Mocks', () => {
    let userService;
    let mockDatabase;

    beforeEach(() => {
        mockDatabase = new Database();
        userService = new UserService(mockDatabase);
    });

    it('should call saveUser when createUser is called', () => {
        const user = { id: '123', name: 'Alice' };

        userService.createUser(user);

        expect(mockDatabase.saveUser).toHaveBeenCalled();
        expect(mockDatabase.saveUser).toHaveBeenCalledWith(user);
    });
});

Explanation

Setup Mocks: Before each test, we set up a mock for the Database class using Jest to simulate the behavior of the saveUser method.
Define Behavior: We ensure that mockDatabase.saveUser is called with the correct user object when createUser is executed.
**Test Case: **We check that createUser correctly calls saveUser with the provided user details.

By using mocks, we isolate the UserService from the actual database and control the test environment, ensuring our tests are reliable and efficient. This approach is common across many programming languages and testing frameworks, making it a universal concept in software development.

Stubs

Stubs, like mocks, are test doubles used to simulate the behavior of real objects in a controlled way during testing. However, there are some key differences between stubs and mocks.

What Are Stubs?

Stubs are predefined responses to specific calls made during the test. Unlike mocks, which can also be used to verify interactions and behaviors (such as ensuring certain methods were called), stubs are primarily focused on providing controlled outputs to method calls.

Why Use Stubs?

Control: Provide predetermined responses to method calls, ensuring consistent test outcomes.
Isolation: Isolate the code under test from external dependencies, similar to mocks.
Simplicity: Often simpler to set up and use when you only need to control return values and not verify interactions.

Real-World Scenario

Consider a scenario where you have a service that calculates the total price of items in a shopping cart. This service relies on another service to fetch the price of each item. During testing, you don’t want to rely on the actual price-fetching service, so you use stubs to simulate the behavior.

Example Code

Service Implementation

// cartService.js
class CartService {
    constructor(priceService) {
        this.priceService = priceService;
    }

    async calculateTotal(cart) {
        let total = 0;
        for (let item of cart) {
            const price = await this.priceService.getPrice(item.id);
            total += price * item.quantity;
        }
        return total;
    }
}

module.exports = CartService;

Test with Stubs

// cartService.test.js
const chai = require('chai');
const sinon = require('sinon');
const CartService = require('./cartService');
const expect = chai.expect;

describe('CartService', () => {
    let priceServiceStub;
    let cartService;

    beforeEach(() => {
        priceServiceStub = {
            getPrice: sinon.stub()
        };
        cartService = new CartService(priceServiceStub);
    });

    it('should calculate the total price of items in the cart', async () => {
        priceServiceStub.getPrice.withArgs(1).resolves(10);
        priceServiceStub.getPrice.withArgs(2).resolves(20);

        const cart = [
            { id: 1, quantity: 2 },
            { id: 2, quantity: 1 }
        ];

        const total = await cartService.calculateTotal(cart);
        expect(total).to.equal(40);
    });

    it('should handle an empty cart', async () => {
        const cart = [];

        const total = await cartService.calculateTotal(cart);
        expect(total).to.equal(0);
    });
});

Explanation

Setup Stubs: Before each test, we create priceServiceStub using Sinon to stub the getPrice method.
Define Behavior: We define the behavior of priceServiceStub for specific inputs:
• withArgs(1).resolves(10) makes getPrice(1) return 10.
•withArgs(2).resolves(20) makes getPrice(2) return 20.
Test Cases:
• In the first test, we verify that calculateTotal correctly computes the total price of the items in the cart.
• In the second test, we verify that calculateTotal returns 0 when the cart is empty.

With stubs we isolate the CartService from the actual price-fetching service and provide controlled return values, ensuring consistent and reliable test outcomes. Stubs are useful when you need to control the return values of methods without verifying the interactions between objects, which makes them a simpler alternative to mocks in many scenarios.

Spies

Spies are another type of test double used in unit testing to observe the behavior of functions. Unlike mocks and stubs, spies are primarily used to monitor how functions are called during the execution of the test. They can wrap existing functions or methods, allowing you to verify if and how they were called, without necessarily altering their behavior.

What Are Spies?

Spies are used to:

Track Function Calls: Check if a function was called, how many times it was called, and with what arguments.
Monitor Interactions: Observe interactions between different parts of the code.
Verify Side Effects: Ensure certain functions are invoked as part of the code execution.

Why Use Spies?

Non-Intrusive: Spies can wrap existing methods without changing their behavior, making them less intrusive.
Verification: Great for verifying that certain methods or functions are called correctly during tests.
Flexibility: Can be used in conjunction with stubs and mocks for comprehensive testing.

Real-World Scenario

Imagine you have a NotificationService that sends notifications and logs these actions. You want to ensure that every time a notification is sent, it is properly logged. Instead of replacing the logging functionality, you can use a spy to monitor the log method calls.

Example Code

NotificationService.ts

export class NotificationService {
    private logger;

    constructor(logger) {
        this.logger = logger;
    }

    sendNotification(message: string) {
        // Simulate sending a notification
        this.logger.log(`Notification sent: ${message}`);
    }
}

Logger.ts

export class Logger {
    log(message: string) {
        console.log(message);
    }
}

Test with Spies

import { NotificationService } from './NotificationService';
import { Logger } from './Logger';
import { jest } from '@jest/globals';

describe('NotificationService - Spies', () => {
    let notificationService;
    let logger;

    beforeEach(() => {
        logger = new Logger();
        notificationService = new NotificationService(logger);
    });

    it('should call log method when sendNotification is called', () => {
        const logSpy = jest.spyOn(logger, 'log');
        const message = 'Hello, World!';

        notificationService.sendNotification(message);

        expect(logSpy).toHaveBeenCalled();
        expect(logSpy).toHaveBeenCalledWith(`Notification sent: ${message}`);
    });
});

Explanation

Setup Service: Before each test, we create a notificationService using a logger instance in order to spy on the log method.
Invoke Methods: We call the sendNotification method on the notificationService instance with a test message.
Verify Calls: We check that the log method is called and with the correct argument when a notification is sent.

Spies allows us to verify that the log method is called as expected without altering its behavior. Spies are especially useful for verifying interactions and side effects in your code, making them a valuable tool for ensuring the correctness of your application's behavior during testing.

Integration Tests

Integration tests are important to verify that the different modules of a software application interact as expected. In contrast to unit tests, which concentrate on single units of code, integration tests assess the collaboration between integrated components, identifying any issues that may result from their combined operation.

What Are Integration Tests?

Combined Components: Integration tests assess how well combined parts of a system work together.
Realistic Environment: These tests often use more realistic scenarios compared to unit tests, involving databases, external APIs, and other system components.
Middleware Testing: They test the middleware and the connections between different parts of the system.

Why Use Integration Tests?

Detect Interface Issues: They help detect issues at the boundaries where different components interact.
Ensure Component Synergy: Verify that different parts of the system work together as expected.
System Reliability: Increase the overall reliability of the system by catching errors that unit tests might miss.
Complex Scenarios: Test more complex, real-world scenarios that involve multiple parts of the system.

Real-World Scenario

Consider a web application with a backend API and a database. You want to ensure that a specific API endpoint correctly retrieves data from the database and returns it in the expected format.

Example Code

Here’s a simple example of an integration test for a Node.js application using Jest and Supertest:

// app.js
const express = require('express');
const app = express();
const { getUser } = require('./database');

app.get('/user/:id', async (req, res) => {
    try {
        const user = await getUser(req.params.id);
        if (user) {
            res.status(200).json(user);
        } else {
            res.status(404).send('User not found');
        }
    } catch (error) {
        res.status(500).send('Server error');
    }
});

module.exports = app;

Integration Tests

// app.test.js
const request = require('supertest');
const app = require('./app');
const { getUser } = require('./database');

jest.mock('./database');

describe('GET /user/:id', () => {
    it('should return a user for a valid ID', async () => {
        const userId = '1';
        const user = { id: '1', name: 'John Doe' };
        getUser.mockResolvedValue(user);

        const response = await request(app).get(`/user/${userId}`);

        expect(response.status).toBe(200);
        expect(response.body).toEqual(user);
    });

    it('should return 404 if user is not found', async () => {
        const userId = '2';
        getUser.mockResolvedValue(null);

        const response = await request(app).get(`/user/${userId}`);

        expect(response.status).toBe(404);
        expect(response.text).toBe('User not found');
    });

    it('should return 500 on server error', async () => {
        const userId = '3';
        getUser.mockRejectedValue(new Error('Database error'));

        const response = await request(app).get(`/user/${userId}`);

        expect(response.status).toBe(500);
        expect(response.text).toBe('Server error');
    });
});

Explanation

Application Setup: The Express application defines a route that fetches a user by ID from a database.
Mocking Dependencies: The getUser function from the database module is mocked to simulate different scenarios.
Test Suite:
• The first test checks if the endpoint returns the correct user data for a valid ID.
• The second test verifies that a 404 status is returned if the user is not found.
• The third test ensures that a 500 status is returned in case of a server error.

Benefits of Integration Tests

Comprehensive Coverage: They provide more comprehensive test coverage by validating interactions between multiple components.
Identify Hidden Issues: Catch bugs that might not be apparent when testing components in isolation.
Increased Confidence: Boost confidence in the system’s overall functionality and reliability.
Real-World Scenarios: Test scenarios that closely mimic real-world usage of the application.

Best Practices for Writing Integration Tests

Realistic Environments: Use environments that closely resemble production to uncover environment-specific issues.
Data Management: Set up and tear down test data to ensure tests run with predictable, known states.
Mock External Services: Mock external dependencies and services to focus on the integration between your components.
Test Key Interactions: Focus on testing critical paths and key interactions between system components.
Combine with Unit Tests: Use integration tests in conjunction with unit tests for thorough coverage.

End-to-End tests

End-to-End (E2E) tests are a type of testing that focuses on verifying the complete functionality of an application, ensuring that it works as intended from start to finish. Unlike unit tests that test individual components or functions, E2E tests simulate real user interactions and test the entire system, including the frontend, backend, and database.

What Are End-to-End Tests?

Test the Complete Workflow: They test the full flow of the application from the user interface (UI) to the backend and back.
Simulate Real User Actions: They simulate user interactions such as clicking buttons, filling out forms, and navigating through the application.
Ensure Integration: They verify that all parts of the system work together correctly.

Why Use End-to-End Tests?

Comprehensive Coverage: They provide the highest level of confidence that the application works as a whole.
Catch Integration Issues: They identify problems that occur when different parts of the system interact.
User-Centric: They validate that the application behaves correctly from the user’s perspective.

Real-World Scenario

Let’s consider a scenario where you have a web application with a user login functionality. An E2E test for this scenario would involve opening the login page, entering a username and password, clicking the login button, and verifying that the user is successfully logged in and redirected to the dashboard.

We will create a simple E2E test using mocha, chai, and supertest to test a Node.js backend application.

Example Code

Backend Route Implementation

// app.js
const express = require('express');
const bodyParser = require('body-parser');
const app = express();

app.use(bodyParser.json());

app.post('/login', (req, res) => {
    const { username, password } = req.body;
    if (username === 'john_doe' && password === 'password123') {
        return res.status(200).send({ message: 'Welcome, John Doe' });
    }
    return res.status(401).send({ message: 'Invalid credentials' });
});

app.get('/dashboard', (req, res) => {
    res.status(200).send({ message: 'This is the dashboard' });
});

module.exports = app;

E2E Test with Mocha, Chai, and Supertest

// app.test.js
const chai = require('chai');
const chaiHttp = require('chai-http');
const app = require('./app');
const expect = chai.expect;

chai.use(chaiHttp);

describe('User Login E2E Test', () => {
    it('should log in and redirect to the dashboard', (done) => {
        chai.request(app)
            .post('/login')
            .send({ username: 'john_doe', password: 'password123' })
            .end((err, res) => {
                expect(res).to.have.status(200);
                expect(res.body).to.have.property('message', 'Welcome, John Doe');

                chai.request(app)
                    .get('/dashboard')
                    .end((err, res) => {
                        expect(res).to.have.status(200);
                        expect(res.body).to.have.property('message', 'This is the dashboard');
                        done();
                    });
            });
    });

    it('should not log in with invalid credentials', (done) => {
        chai.request(app)
            .post('/login')
            .send({ username: 'john_doe', password: 'wrongpassword' })
            .end((err, res) => {
                expect(res).to.have.status(401);
                expect(res.body).to.have.property('message', 'Invalid credentials');
                done();
            });
    });
});

Explanation

Setup Test: We describe a test suite (describe) and test cases (it) using Mocha and Chai.
Simulate User Actions:
• We use chai.request(app) to simulate HTTP requests to the application.
• .post('/login') sends a POST request to the login endpoint with the username and password.
• .send({ username: 'john_doe', password: 'password123' }) sends the login credentials.
Verify Outcomes:
• We check the response status and message to verify successful login.
• We send a GET request to the dashboard endpoint and check the response to verify access to the dashboard after login.
Handle Errors: We also test the scenario where login credentials are invalid and verify the appropriate error message and status code.

Benefits of E2E Testing

User Experience Validation: E2E tests ensure that the application provides a good user experience.
Comprehensive Testing: They test the entire application stack, catching issues that unit or integration tests might miss.
Automation: E2E tests can be automated, allowing you to run them as part of your CI/CD pipeline to catch issues before deployment.

End-to-End tests are crucial for validating the full functionality and user experience of your application. They **ensure that all parts of your system work together **and that real-world user scenarios are handled correctly. Using tools like Mocha, Chai, and Supertest, you can automate these tests to maintain high confidence in the quality and reliability of your application.

Code Coverage

Code coverage is a metric used in software testing to measure the extent to which the source code of a program is executed when a particular test suite runs. It helps determine how much of your code is being tested and can identify areas of the codebase that are not covered by any tests.

Key Concepts of Code Coverage

Statement Coverage: Measures the percentage of executable statements that have been executed.
Branch Coverage: Measures the percentage of branches (decision points like if-else conditions) that have been executed.
Function Coverage: Measures the percentage of functions or methods that have been called.
Line Coverage: Measures the percentage of lines of code that have been executed.
Condition Coverage: Measures the percentage of boolean sub-expressions within conditionals that have been evaluated to both true and false.

Why Use Code Coverage?

Identify Untested Code: Helps you find parts of your codebase that are not covered by tests.
Improve Test Quality: Ensures that your tests are thorough and cover various scenarios.
Maintain Code Quality: Promotes better code maintenance practices by encouraging more comprehensive testing.
Reduce Bugs: Increases the likelihood of catching bugs and errors by ensuring more of your code is tested.

Example of Code Coverage

Consider a simple function and its tests:

Implementation

// math.js
function add(a, b) {
    return a + b;
}

function multiply(a, b) {
    return a * b;
}

function subtract(a, b) {
    return a - b;
}

module.exports = { add, multiply, subtract };

Tests

// math.test.js
const chai = require('chai');
const expect = chai.expect;
const { add, multiply, subtract } = require('./math');

describe('Math Functions', () => {
    it('should add two numbers', () => {
        expect(add(2, 3)).to.equal(5);
    });

    it('should multiply two numbers', () => {
        expect(multiply(2, 3)).to.equal(6);
    });

    it('should subtract two numbers', () => {
        expect(subtract(5, 3)).to.equal(2);
    });
});

Generating Code Coverage

To measure code coverage, we can use a tool like Istanbul (now called NYC). Here’s how you can set it up:

Install NYC: First, install NYC as a development dependency.

npm install --save-dev nyc

Configure NYC: Add a configuration in your package.json or create an .nycrc file.

// package.json
"nyc": {
    "reporter": ["html", "text"],
    "exclude": ["test"]
}

Run Tests with Coverage: Modify your test script to include NYC.

// package.json
"scripts": {
    "test": "nyc mocha"
}

Execute Tests: Run your tests with the coverage command.

    npm test

Interpreting Code Coverage Reports

After running the tests, NYC will generate a coverage report. The report typically includes:

Summary: A summary of coverage percentages for statements, branches, functions, and lines.
Detailed Report: A detailed report showing which lines of code were covered and which were not.

Example output (simplified):

=============================== Coverage summary ===============================
Statements   : 100% ( 12/12 )
Branches     : 100% ( 4/4 )
Functions    : 100% ( 3/3 )
Lines        : 100% ( 12/12 )
================================================================================

Code coverage is a nice metric in software testing that helps ensure your code is well-tested and reliable. By using tools like NYC, you can measure and visualize how much of your code is covered by tests, identify gaps, and improve the overall quality of your codebase. High code coverage can significantly reduce the risk of bugs and improve the maintainability of your software.

Test Driven Development

Test Driven Development (TDD) is a software development approach where tests are written before the actual code. The process emphasizes writing a failing test first, then writing the minimal amount of code needed to pass that test, and finally refactoring the code to meet acceptable standards. TDD aims to ensure that code is reliable, maintainable, and meets the requirements from the start.

Key Concepts of Test Driven Development

Red-Green-Refactor Cycle:
• Red: Write a test for a new function or feature. Initially, the test will fail because the feature hasn’t been implemented yet.
• Green: Write the minimal amount of code necessary to make the test pass.
• Refactor: Refactor the new code to improve its structure and readability without changing its behavior. Ensure all tests still pass after refactoring.
Small Iterations: TDD encourages small, incremental changes. Each iteration involves writing a test, making it pass, and then refactoring.
Focus on Requirements: Writing tests first forces developers to consider the requirements and design of the feature before implementation.

Why Use Test Driven Development?

Improved Code Quality: TDD leads to better-designed, cleaner, and more maintainable code.
Less Debugging: Bugs are caught early in the development process, reducing the time spent on debugging.
Better Requirements Understanding: Writing tests first helps clarify requirements and design before implementation.
High Test Coverage: Since tests are written for every feature, TDD ensures high code coverage.

Example of Test Driven Development

Let’s walk through a simple example of implementing a function to check if a number is prime using TDD in JavaScript with Mocha and Chai.

Step 1: Write a Failing Test (Red)

First, we write a test for a function isPrime that doesn't exist yet.

// isPrime.test.js
const chai = require('chai');
const expect = chai.expect;
const { isPrime } = require('./isPrime');

describe('isPrime', () => {
    it('should return true for prime number 7', () => {
        expect(isPrime(7)).to.be.true;
    });

    it('should return false for non-prime number 4', () => {
        expect(isPrime(4)).to.be.false;
    });

    it('should return false for number 1', () => {
        expect(isPrime(1)).to.be.false;
    });

    it('should return false for number 0', () => {
        expect(isPrime(0)).to.be.false;
    });

    it('should return false for negative numbers', () => {
        expect(isPrime(-3)).to.be.false;
    });
});

Run the test, and it will fail since the isPrime function is not defined yet.

Step 2: Write Minimal Code to Pass the Test (Green)

Next, we write the minimal code needed to pass the test.

// isPrime.js
function isPrime(num) {
    if (num <= 1) return false;
    for (let i = 2; i < num; i++) {
        if (num % i === 0) return false;
    }
    return true;
}

module.exports = { isPrime };

Run the test again. This time, it should pass.

Step 3: Refactor the Code

Finally, we refactor the code to improve its efficiency and readability without changing its behavior.

// isPrime.js
function isPrime(num) {
    if (num <= 1) return false;
    if (num <= 3) return true;
    if (num % 2 === 0 || num % 3 === 0) return false;
    for (let i = 5; i * i <= num; i += 6) {
        if (num % i === 0 || num % (i + 2) === 0) return false;
    }
    return true;
}

module.exports = { isPrime };

Run the tests again to ensure they all still pass after the refactoring.

Benefits of TDD

Confidence in Code: Ensures that code changes do not introduce new bugs.
Documentation: Tests serve as a form of documentation, providing examples of how the code is supposed to work.
Design Improvements: Encourages better software design and architecture.
Reduced Debugging Time: Early bug detection minimizes the time spent on debugging.

Test Driven Development (TDD) is a powerful methodology that helps developers create high-quality, reliable, and maintainable code. By following the Red-Green-Refactor cycle, developers can ensure their code meets requirements from the start and maintain high test coverage. TDD leads to better design, less debugging, and more confidence in the codebase.

Behavior Driven Development

Behavior Driven Development (BDD) is a software development methodology that extends the principles of Test Driven Development (TDD) by focusing on the behavior of the system from the perspective of its stakeholders. BDD emphasizes collaboration between developers, testers, and business stakeholders to ensure that the software meets the desired behaviors and requirements.

Key Concepts of Behavior Driven Development

Shared Understanding: BDD encourages collaboration and communication among team members to ensure everyone has a clear understanding of the desired behavior of the system.
User Stories and Scenarios: BDD uses user stories and scenarios to describe the expected behavior of the system in plain language that can be understood by both technical and non-technical stakeholders.
Given-When-Then Syntax: BDD scenarios typically follow a structured format known as Given-When-Then, which describes the initial context (Given), the action being performed (When), and the expected outcome (Then).
Automated Acceptance Tests: BDD scenarios are often automated using testing frameworks, allowing them to serve as both executable specifications and regression tests.

Why Use Behavior Driven Development?

Clarity and Understanding: BDD promotes a shared understanding of requirements among team members, reducing ambiguity and misunderstandings.
Alignment with Business Goals: By focusing on behaviors and user stories, BDD ensures that development efforts are aligned with business objectives and user needs.
Early Detection of Issues: BDD scenarios serve as early acceptance criteria, allowing teams to detect issues and misunderstandings early in the development process.
Improved Collaboration: BDD encourages collaboration between developers, testers, and business stakeholders, fostering a shared sense of ownership and responsibility for the quality of the software.

Example of Behavior Driven Development

Let’s consider a simple example of implementing a feature to withdraw money from an ATM using BDD with Gherkin syntax and Cucumber.js.

Feature File (ATMWithdrawal.feature)

Feature: ATM Withdrawal
  As a bank customer
  I want to withdraw money from an ATM
  So that I can access my funds

  Scenario: Withdrawal with sufficient balance
    Given my account has a balance of $100
    When I withdraw $20 from the ATM
    Then the ATM should dispense $20
    And my account balance should be $80

  Scenario: Withdrawal with insufficient balance
    Given my account has a balance of $10
    When I withdraw $20 from the ATM
    Then the ATM should display an error message
    And my account balance should remain $10

Step Definitions (atmWithdrawal.js)

const { Given, When, Then } = require('cucumber');
const { expect } = require('chai');

let accountBalance = 0;
let atmBalance = 100;

Given('my account has a balance of ${int}', function (balance) {
    accountBalance = balance;
});

When('I withdraw ${int} from the ATM', function (amount) {
    if (amount > accountBalance) {
        this.errorMessage = 'Insufficient funds';
        return;
    }
    accountBalance -= amount;
    atmBalance -= amount;
    this.withdrawnAmount = amount;
});

Then('the ATM should dispense ${int}', function (amount) {
    expect(this.withdrawnAmount).to.equal(amount);
});

Then('my account balance should be ${int}', function (balance) {
    expect(accountBalance).to.equal(balance);
});

Then('the ATM should display an error message', function () {
    expect(this.errorMessage).to.equal('Insufficient funds');
});

Running the Scenarios

You can run the scenarios using Cucumber.js, which will parse the feature file, match the steps to their definitions, and execute the tests.

Benefits of BDD

Shared Understanding: Promotes a shared understanding of requirements among team members.
Alignment with Business Goals: Ensures that development efforts are aligned with business objectives and user needs.
Early Detection of Issues: BDD scenarios serve as early acceptance criteria, allowing teams to detect issues and misunderstandings early in the development process.
Improved Collaboration: Encourages collaboration between developers, testers, and business stakeholders, fostering a shared sense of ownership and responsibility for the quality of the software.

Behavior Driven Development (BDD) is a powerful methodology for developing software that focuses on the behaviors and requirements of the system from the perspective of its stakeholders. By using plain language scenarios and automated tests, BDD promotes collaboration, shared understanding, and alignment with business goals, ultimately leading to higher quality software that better meets the needs of its users.

Conclusion

Understanding and implementing effective testing strategies is a fundamental principle for a professional software development. By leveraging Mocks, Stubs, and Spies, developers can isolate and test individual components, ensuring each part functions correctly. End-to-End Testing provides confidence that the entire system works harmoniously from the user’s perspective. Code Coverage metrics help identify gaps in testing, driving improvements in test comprehensiveness. Applying Test Driven Development (TDD) and Behavior Driven Development (BDD) fosters a culture of quality, clarity, and collaboration, ensuring that software not only meets technical requirements but also aligns with business goals and user expectations. As developers, applying and refining these practices over time allows us to build more reliable, sustainable, and successful software solutions.

The Potential of Monolithic Systems

Ewerson Vieira Nascimento — Sun, 08 Sep 2024 23:43:49 +0000

Monolithic systems are often seen as outdated systems and bad practice when thinking about building scalable systems nowadays. In this article we will see why these arguments are false, how to get the best out of monolithic architecture and how it can be a springboard for implementing microservices in your application in the future.

What it is

At its core, a monolithic system encapsulates an “all-in-one” architecture, where all components of an application are interconnected and deployed as a single unit.

Myths about monolithic architecture

Monolithic systems have their limitations and challenges, but many of the criticisms leveled against them are based on false assumptions or outdated perceptions:

Monolithic Systems Are Outdated: Despite misconceptions, monolithic architectures remain relevant in modern software development, with many successful applications still utilizing them (Shopify is an example).
Monolithic Systems Do Not Scale: While scaling monolithic systems poses challenges compared to microservices, they can handle significant loads with proper design and optimization.
Monolithic Systems Impede Business Growth: Contrary to claims, monolithic architectures can provide stability and support iterative development, especially beneficial for startups or rapidly evolving businesses.
Monolithic Systems Have High Coupling: Critics often exaggerate tight coupling issues, which can be mitigated through proper design principles and practices (modular monoliths).
Monolithic Systems Cannot Support Microservices Architecture: Monolithic systems can be refactored into microservices incrementally, allowing for a gradual transition without sacrificing stability.

Different types of monolithic systems

Single-Process Monoliths: These monolithic systems are characterized by a singular focus, where all components of the application reside within a single process. While offering simplicity in design, they can suffer from high coupling between modules.

Distributed Monoliths: Distributed monoliths extend the single-process model by distributing components across multiple servers or nodes while maintaining a monolithic architecture. This approach aims to alleviate scalability concerns but may introduce additional complexity in deployment and maintenance.

Black Box Monoliths: In a black box monolithic architecture, the internal workings of the system are opaque, resembling a closed system where interactions are limited to predefined interfaces. While providing encapsulation and abstraction, black box monoliths may create challenges in understanding and debugging.

Each type of monolithic system comes with its own set of advantages and challenges, according to different requirements and contexts in software development.

When monolithic architecture should be used?

Whenever you want to achieve simplicity, stability, and a unified deployment model you should start with monolithic architecture, but here are some specific situations where using monolithic systems may be beneficial:

Unclear Business Model: In the early stages of a project or when the business model is still evolving, monolithic architectures provide a straightforward development approach. They allow teams to focus on building core functionality without the added complexity of distributed systems.

Core Business Instability: When the core functionalities of an application are subject to frequent changes or uncertainty, a monolithic architecture can provide stability. It simplifies development and maintenance efforts, enabling teams to iterate on features efficiently amidst evolving business requirements.

Simplicity in Deployment: Monolithic systems streamline the deployment process by consolidating all components into a single unit. This simplicity is advantageous in environments where rapid deployment and iteration are crucial, such as small-scale projects or startups.

Operational Simplicity: Organizations with limited resources or operational expertise may prefer monolithic architectures for their simplicity in management and operation. With a single codebase and deployment unit, monitoring, scaling, and troubleshooting become more straightforward tasks.

Transitioning to Microservices: In cases where a future transition to microservices architecture is anticipated, starting with a monolithic system can serve as a pragmatic approach. It allows teams to validate business logic, refine domain boundaries, and gain insights into performance bottlenecks before embarking on a microservices journey. But, in order to do it properly, it’s important to implement a modular monolith.

Strategies to reduce coupling

In order to reduce coupling when building monoliths it’s a good practice to break down the monolithic application into smaller, more manageable modules based on functional boundaries or domain concepts. Each module should encapsulate related functionality and shouldn’t depend on other modules, reducing overall coupling. To achieve this kind of modularity we can apply the following concepts:

Domain-Driven Design (DDD): Adopting DDD principles helps identify and define bounded contexts within the system. By emphasizing domain modeling and ubiquitous language, we can create cohesive and loosely coupled modules, each dealing with a single bounded context.

Communication through Contracts and Facades: Implementing facades will define a clear communication protocol between the modules, encapsulating complex interactions and providing the possibility to completely replace a module in the future without affecting the other modules (Dependency Inversion Principle).

Selective Duplication of Entities: Entities shared across multiple modules can lead to tight coupling. In order to avoid inter-module dependency, in this case we can duplicate entities, making them point to the same database tables and share the same IDs, but having the flexibility to name them according to the context (users, clients, beneficiary, people, etc.) and use only the necessary attributes in each module.

Specialized Teams or Ownership: Assign dedicated teams or ownership responsibilities for individual modules. By having specialized teams focused on specific modules, development efforts become more focused, and dependencies between teams can be minimized, reducing coupling.

High Cohesion: Aim for high cohesion within modules, ensuring that related functionalities are grouped together. Modules with high cohesion tend to have fewer external dependencies and are easier to understand, maintain, and evolve.

Key benefits of modular monoliths

Overall, modular monolithic systems strike a balance between modularity and simplicity, offering many of the benefits associated with microservices architectures while maintaining the operational ease of traditional monolithic systems.

Unified Deployment: Modular monolithic systems allow for a single deployment unit, simplifying the deployment process instead of managing multiple components separately.

Unified Operation: Similarly, the operational aspects of a modular monolithic system are streamlined. Monitoring, scaling, and managing the system can be done holistically, as there is only one operational entity to oversee.

Simplified Observability: With all components of the system tightly integrated, observability becomes more straightforward. Monitoring, logging, and debugging are centralized, making it easier to identify and troubleshoot issues across the entire system. This simplification accelerates problem resolution and improves system reliability.

Lower Latency and Reduced Network Overhead: In a modular monolithic architecture, communication between modules typically occurs within the same process or server, leading to lower latency and reduced network overhead compared to distributed systems. This can result in faster response times and improved performance, especially in latency-sensitive applications.

Consistency in Technology Stack and Governance: Since all components of a modular monolithic system are developed and maintained within the same codebase, there is consistency in the technology stack and development practices. This coherence simplifies governance, reduces compatibility issues, and promotes collaboration among development teams.

Easier Development and Testing: Developers working on a modular monolithic system can have a clear understanding of the entire system architecture and can easily navigate between modules. This facilitates collaborative development and testing, as changes in one module can be quickly validated against the entire system.

While studying this topic I’ve created this repository. It contains a monolith with 6 modules and a small shared kernel between them. These modules were developed with TypeScript, using DDD, and they communicate with each other using facades.

In summary, monolithic systems, often underestimated in today’s tech landscape, offer pragmatic solutions for various development scenarios. By dispelling myths and exploring different types of monolithic architectures, we uncover their strengths in providing stability and simplicity. With strategic approaches to reducing coupling and embracing modularity, monolithic systems can serve as effective platforms for transitioning to microservices. Harnessing their potential enables teams to build scalable, innovative, and resilient applications while meeting the evolving business needs.

Understanding Clean Architecture Principles

Ewerson Vieira Nascimento — Sun, 08 Sep 2024 23:41:17 +0000

In the world of software development we’re always on the lookout for methods that make our lives easier while building better software. Clean Architecture shines as one such method. It’s a structured approach that combines the best of software architecture fundamentals, Domain-Driven Design (DDD), and Hexagonal Architecture. Let’s dig into some of its principles and see what makes it so special.

Consolidating Software Architecture Fundamentals:

Clean Architecture emphasizes the separation of concerns and the organization of code into distinct layers. By applying this principle, developers ensure that each component of the system has a single responsibility, making the codebase easier to understand, maintain, and extend.

Protecting the Domain:

One of the goals of Clean Architecture is to protect the domain of the application. This means isolating business logic and domain-specific rules from external dependencies like frameworks, libraries, and databases so that changes in these external factors do not directly impact the core business logic, promoting flexibility and adaptability.

Low Coupling Between Layers:

Clean Architecture advocates for low coupling between layers, enforcing clear boundaries between different architectural elements with each layer acting as an architectural limit. This separation enables components to evolve independently, reducing the ripple effect of changes and promoting modularization.

Use Case-Oriented Design:

A distinguishing feature of Clean Architecture is its focus on use cases or the intentions of performing actions within the system. By organizing code around these use cases, developers can align software design with real-world scenarios, enhancing clarity and maintainability.

Postponing Decisions and Focusing on Business Rules:

Clean Architecture encourages deferring decisions about technical details such as frameworks, databases, or UI implementations. Instead, developers focus on capturing and implementing business rules effectively. This approach allows for greater flexibility in adapting to changing requirements and technological advancements.

Data Flow from Access to Presentation:

In Clean Architecture, the flow of data follows a clear path from the outer layers (such as the presentation layer or UI) to the inner layers (such as the domain and data layers) and back. This flow ensures that business logic remains agnostic of presentation or database concerns and facilitates testing and maintainability.

While studying about Clean Architecture I’ve built this repository to implement and practice some of its principles. It was not made to be perfect, but to give an idea of how we can use clean architecture in a TypeScript backend.

In summary, Clean Architecture provides a solid framework for creating software that’s easy to maintain, scalable, and aligned with business objectives by emphasizing core software principles, safeguarding the domain, minimizing dependencies between layers, and giving top priority to the business logic in order to build better software solutions.

Exploring Hexagonal Architecture

Ewerson Vieira Nascimento — Sun, 08 Sep 2024 23:37:18 +0000

Hexagonal Architecture, also known as Ports and Adapters, originally introduced by Alistair Cockburn in 2005, has gained significant traction due to its emphasis on separating concerns and promoting modularity. In this article, we’ll see the core objectives of Hexagonal Architecture, its role in decoupling technical complexity from business logic, and its utilization of the Dependency Inversion Principle for enhanced componentization.

Understanding Hexagonal Architecture

The primary goal of Hexagonal Architecture is to facilitate the development of software systems that are adaptable, maintainable, and easily testable. At its core, this architectural style revolves around the concept of a hexagon, with the application’s core business logic situated at its center. Surrounding this core are various layers, or ports, through which the application interacts with external systems, such as databases, user interfaces, or third-party services.

Separating Technical and Business Concerns

One of the key advantages of Hexagonal Architecture is its ability to segregate technical complexities from the core business logic. By defining clear boundaries between different layers of the system, Hexagonal Architecture ensures that changes in one area do not ripple through the entire codebase. This separation allows developers to focus on implementing and evolving business rules independently of the technical infrastructure.

Isolation from External Dependencies

Hexagonal Architecture also promotes the isolation of the application from its external dependencies. Through the use of adapters, the system can interact with external components without being tightly coupled to their implementations. This isolation not only enhances flexibility but also simplifies the process of integration and testing. Additionally, it enables easier swapping of components, making the system more resilient to changes in the external environment.

Dependency Inversion Principle in Action

The Dependency Inversion Principle (DIP) states that high-level modules should not depend on low-level modules; both should depend on abstractions. Hexagonal Architecture embodies this principle by introducing clear interfaces, or ports, between different components of the system. This abstraction layer allows for the inversion of dependencies, enabling high-level modules, such as business logic, to remain agnostic to the specific implementations of lower-level components, such as data access or external services.

Example Implementation

An implementation that could be used as an example of how Hexagonal Architecture works can be found in this repository. It showcases how the principles of Hexagonal Architecture can be applied in a real-world scenario, using the Go programming language.

In this implementation, the core business logic is encapsulated within the application’s internal package, while the external dependencies, such as database access and HTTP communication, are defined in the adapters package. Adapters implement the interfaces defined by the application package, thereby enabling the application to interact with external systems while maintaining loose coupling and flexibility.

PS: The code was developed for study purposes, so don’t mind all the refactoring it requires.

Conclusion

Hexagonal Architecture, with its focus on separation of concerns and dependency inversion, provides a solid foundation for building modular, maintainable software systems. By isolating technical complexities, decoupling external dependencies, and embracing principles like the Dependency Inversion Principle, Hexagonal Architecture empowers developers to create adaptable solutions that can evolve with changing requirements and environments.

A Quick Introduction to Event Storming

Ewerson Vieira Nascimento — Sun, 08 Sep 2024 23:33:15 +0000

When talking about system design, there’s a powerful tool used to obtain a better understanding of what should be built: Event Storming, a teamwork technique that acts as your compass to solve the complexities of business processes and system structures. In this guide, we’ll explore the basics of Event Storming through some small real-life examples.

1. Getting Ready: Set the Stage

Before diving in, gather a team with different skills — experts, developers, and stakeholders. Grab your team, sticky notes, and markers (or use a tool like Miro). Clearly define what you want to achieve in your modeling session — maybe defining how the refund feature should work in your system.

2. Actors: Who’s in the Mix

Actors are the individuals or external systems interacting with your system. In a cinema booking system, the actors could be customers (users) initiating actions like BookTicket or CancelReservation.

Defining Actors: Ask, “Who interacts with our system? What roles do users or external systems play in our scenario?”

3. Commands: Actions That Matter

Commands are the actions triggering changes in your system — user or system-initiated moves. In the cinema system, a command might be PlaceOrder when a customer decides to book tickets.

Defining Commands: Explore actions users can make: “What actions can users take, and when do these actions occur in the system?”

4. Events: The Big Moments

Events are significant occurrences affecting your system. In the cinema system, TicketBooked or ReservationCancelled are events marking key moments.

Defining Events: Identify moments of change: “What significant occurrences or state changes happen in response to user actions or external factors?”

5. Time-Triggered Events: Scheduled Surprises

Time-triggered events occur at predefined intervals, independent of external stimuli. In our cinema scenario, DiscountApplied every Monday at 5 PM is a time-triggered event.

Defining Time-Triggered Events: Consider scheduled impacts: “What events occur at specific times or intervals, regardless of user actions?”

6. Policies: Keeping Things in Check

Policies are rules governing system behavior. A policy in the cinema system might be “Tickets can be canceled within 24 hours of booking.”

Defining Policies: Establish governing rules: “What rules or constraints should guide the behavior of our system?”

7. Aggregates: Bundling Things Together

Aggregates are clusters of related entities treated as a single unit. In the cinema system, an aggregate could be a Movie with entities like Showtime and Seat.

Defining Aggregates: Group related entities and define rules: “What entities are closely related, and what rules maintain their consistency?”

8. Boundaries: Where Things Happen

Boundaries set limits for different parts of your system. Define clear distinctions between the Booking and Payment subsystems in the cinema system.

Defining Boundaries: Clarify subsystem limits: “What are the distinct parts of our system, and how can we manage their complexity independently?”

Conclusion

Event Storming goes beyond sticky notes and brainstorming; it’s a hands-on journey. By utilizing key components such as actors, commands, events, time-triggered events, policies, aggregates, and boundaries, you gain a clearer path through the complexities of your cinema booking system or any project.

Understanding Domain Events in TypeScript: Making Events Work for You

Ewerson Vieira Nascimento — Sun, 08 Sep 2024 23:30:18 +0000

The Lowdown on Domain Events

When we talk about Domain-Driven Design (DDD), Domain Events serve as messengers, announcing significant changes within the system. These events act as crucial bridges, allowing different parts of your application to stay informed about relevant occurrences, fostering decoupling and maintainability.

What Are Domain Events?

Domain Events are lightweight, immutable objects representing state changes or occurrences within your application’s domain. They encapsulate essential information about what happened without carrying the weight of complex logic. Examples could range from a new user registration to an order being shipped.

Creating Domain Events in TypeScript

In TypeScript, creating a Domain Event is straightforward. Let’s consider a ProductCreatedEvent:

import EventInterface from "../../@shared/event/event.interface";

export default class ProductCreatedEvent implements EventInterface {
    dataTimeOccurred: Date;
    eventData: any;

    constructor(eventData: any) {
        this.dataTimeOccurred = new Date();
        this.eventData = eventData;
    }
}

Here, the event captures whatever data we want to register and the exact time it happened. It’s a simple data structure designed for communication.

Handlers and Why They Matter

Event Handlers are responsible for reacting to Domain Events. They encapsulate the logic triggered by an event. For instance, when a ProductCreatedEvent occurs, you might want to send an email or log the event.

import EventHandlerInterface from "../../../@shared/event/event-handler.interface";
import ProductCreatedEvent from "../product-created.event"

export default class SendEmailWhenProductIsCreatedHandler implements EventHandlerInterface<ProductCreatedEvent> {
    handle(event: ProductCreatedEvent): void {
        console.log("Sending email to ...");
    }
}

Handlers keep your code modular and focused. Each handler takes care of a specific event, avoiding clutter and maintaining clarity.

Dispatching Events

Event Dispatchers act as messengers, delivering events to their respective handlers. Dispatching involves notifying interested parties that an event has occurred, triggering the associated logic. Here’s a simple event dispatcher:

import EventDispatcherInterface from "./event-dispatcher.interface";
import EventHandlerInterface from "./event-handler.interface";
import EventInterface from "./event.interface";

export default class EventDispatcher implements EventDispatcherInterface {
    private eventHandlers: { [eventName: string]: EventHandlerInterface[] } = {};

    get getEventHandlers(): { [eventName: string]: EventHandlerInterface[] } {
        return this.eventHandlers;
    }

    notify(event: EventInterface): void {
        const eventName = event.constructor.name;
        if (this.eventHandlers[eventName]) {
            this.eventHandlers[eventName].forEach((eventHandler) => {
                eventHandler.handle(event);
            });
        }
    }

    register(eventName: string, eventHandler: EventHandlerInterface<EventInterface>): void {
        if (!this.eventHandlers[eventName]) {
            this.eventHandlers[eventName] = [];
        }
        this.eventHandlers[eventName].push(eventHandler);
    }

    unregister(eventName: string, eventHandler: EventHandlerInterface<EventInterface>): void {
        if (this.eventHandlers[eventName]) {
            const index = this.eventHandlers[eventName].indexOf(eventHandler);
            if (index !== -1) {
                this.eventHandlers[eventName].splice(index, 1);
            }
        }
    }

    unregisterAll(): void {
        this.eventHandlers = {};
    }
}

In this example, the EventDispatcher maintains a collection of event handlers and is responsible for registering, unregistering and dispatching events accordingly.

Putting It All Together

Let’s bring these concepts together with a practical example:

it("Should notify all event handlers", () => {
    const eventDispatcher = new EventDispatcher();
    const eventHandler = new SendEmailWhenProductIsCreatedHandler();
    const spyEventHandler = jest.spyOn(eventHandler, "handle");

    eventDispatcher.register("ProductCreatedEvent", eventHandler);

    expect(eventDispatcher.getEventHandlers["ProductCreatedEvent"][0]).toMatchObject(eventHandler);

    const productCreatedEvent = new ProductCreatedEvent({
        name: "Product 1",
        description: "Product 1 description",
        price: 10.0
    });

    // When notify is executed SendEmailWhenProductIsCreatedHandler.handle() must be called
    eventDispatcher.notify(productCreatedEvent);

    expect(spyEventHandler).toHaveBeenCalled();
});

In this scenario, when the ProductCreatedEvent is dispatched, the associated handler (SendEmailWhenProductIsCreatedHandler) reacts by logging message.

By embracing Domain Events, Handlers, and Dispatchers, you enhance the flexibility, maintainability, and scalability of your applications. These practices encourage a loosely coupled architecture, allowing you to adapt and extend your system more efficiently as your domain evolves.

Unraveling the Complexities of Software Design with Domain-Driven Design (DDD)

Ewerson Vieira Nascimento — Thu, 01 Aug 2024 23:45:33 +0000

Domain-Driven Design (DDD) appears as a beacon of clarity amid the tumultuous seas of software architecture when it comes to creating scalable and sustainable solutions. In this deep dive, we will explore the multifaceted landscape of DDD, dissecting its core concepts and methodologies, and uncovering how it navigates the complexities inherent in modern software development.

Understanding the Domain

At the heart of DDD lies a profound emphasis on the “domain” — the pulsating core of knowledge and activity that defines a system. To grasp this concept, let’s consider an illustrative example — an e-commerce platform. The overarching domain here is the entirety of the e-commerce ecosystem, encompassing various specialized areas of expertise known as “subdomains.” These subdomains could include order management, inventory control, customer relations, and more.

The elegance of DDD lies in its modular approach, allowing development teams to focus on distinct subdomains, akin to specialized departments in an organization. This not only enhances efficiency but also facilitates a deeper understanding of specific aspects of the system. Each subdomain becomes a microcosm, fostering a more manageable and targeted development process.

Contexts in DDD

Within each subdomain, DDD introduces the concept of “contexts” — demarcated territories that establish the rules and boundaries governing a specific area of expertise. Let’s delve into the order management subdomain of our e-commerce example. In this context, the rules may dictate the lifecycle of an order, from creation to processing and eventual fulfillment. The inventory control context, on the other hand, would define how inventory levels are managed, restocked, and synchronized with orders.

By defining contexts, DDD brings clarity to the development process. It ensures that terms, rules, and interactions have precise meanings within a particular context, preventing potential misunderstandings across the broader system. DDD emphasizes the distinction between the “problem space” — the real-world challenges within a domain — and the “solution space” — the software solutions crafted to address those challenges.

Bounded Contexts: The Monarchy of Context

The linchpin of DDD is the “bounded context” — a meticulously defined boundary within which a particular model or concept holds sway. Returning to our e-commerce example, within the order management subdomain, a bounded context would encapsulate specific rules and definitions for order status, payment processing, and shipment tracking.

These bounded contexts serve as crucibles of truth within the broader domain. The mantra of DDD, “context is king,” underscores the critical importance of aligning software models with the ever-evolving business context. Just as a term might have different meanings in different departments of a company, DDD recognizes the need for precision within these boundaries. It ensures that when developers refer to an “order” within the order management context, they share a common understanding and avoid ambiguity.

Navigating Transversal Elements

In the dynamic realm of DDD, transversal elements, such as entities, often traverse multiple contexts, introducing challenges of consistency and autonomy. Consider a customer entity that exists both in the order management and customer relations contexts. DDD equips developers with strategic tools to navigate these complexities.

One such tool is the identification of shared kernels — core elements shared across contexts to maintain consistency. Additionally, the creation of anticorruption layers helps translate between different models, ensuring that the autonomy of individual contexts remains intact. The astute utilization of separate ways allows entities or concepts to evolve independently in their respective contexts without compromising the overall integrity of the system.

Strategic Vision in DDD

To provide a compass for the design and development process, DDD advocates for a strategic vision that aligns software architecture with business goals. Context mapping, a vital element of strategic vision, enables teams to visualize relationships between different bounded contexts. This becomes particularly crucial in our e-commerce example, where the order management and inventory control contexts must seamlessly integrate to ensure a smooth customer experience.

Various patterns, each with its unique characteristics, emerge as indispensable tools in this strategic vision. Let’s delve into these patterns to understand how they contribute to the overall success of DDD:

Partnership: Encourages collaboration between different bounded contexts, fostering a shared understanding and ensuring a seamless flow of information between them.
Shared Kernel: Allows for the sharing of core elements between bounded contexts, promoting consistency where appropriate.
Customer-Supplier Development: Defines clear dependencies between contexts, ensuring that one context is developed with a specific consumer (customer) in mind.
Conformist: Ensures alignment with a shared standard, guiding the development of individual contexts to adhere to established norms.
Anticorruption Layer: Mitigates the impact of changes in one context on another by introducing a layer that translates between different models, preserving the autonomy of each context.
Open Host Service: Facilitates seamless integration between contexts by providing an open and accessible service.
Published Language: Establishes a common vocabulary across contexts, promoting a shared understanding of terms and concepts.
Separate Ways: Allows for the independent evolution of entities or concepts in their respective contexts, preventing unnecessary dependencies.
Big Ball of Mud: Serves as a cautionary tale, reminding developers of the consequences of neglecting DDD principles and allowing a system to devolve into an unmanageable mess.

In the ever-evolving landscape of software development, Domain-Driven Design stands as a beacon, offering a robust framework to tackle complexities head-on. By championing a deep understanding of the business domain, DDD empowers development teams to craft more effective, modular, and maintainable solutions. With concepts like bounded contexts, strategic vision, and context mapping, DDD equips developers with powerful tools to navigate the intricate seas of modern software design, fostering collaboration and ensuring that context remains the reigning monarch throughout the development journey. As we set sail into the future of software development, let Domain-Driven Design be our trusted compass, guiding us through the turbulent waters towards success and innovation.

Understanding SOLID Principles: A Guide for Junior Developers

Ewerson Vieira Nascimento — Thu, 01 Aug 2024 23:41:42 +0000

Introduction to SOLID

SOLID is a set of five design principles that help developers create maintainable and scalable software. These principles were introduced by Robert C. Martin and have become fundamental in object-oriented programming. The SOLID acronym stands for:

S — Single Responsibility Principle (SRP)
O — Open Closed Principle (OCP)
L — Liskov Substitution Principle (LSP)
I — Interface Segregation Principle (ISP)
D — Dependency Inversion Principle (DIP)

Let’s delve into each of these principles with practical TypeScript examples to make them more digestible.

Single Responsibility Principle (SRP)

The SRP states that a class should have only one reason to change. In other words, a class should have only one responsibility. This promotes code modularity and makes the codebase easier to understand and maintain.

class Report {
  generate() {
    // Code to generate the report
  }

  saveToFile() {
    // Code to save the report to a file
  }
}

In the example above, the Report class violates the SRP because it has both the responsibility of generating a report and saving it to a file. We can refactor it by creating a separate class for file handling:

class Report {
  generate() {
    // Code to generate the report
  }
}

class FileManager {
  saveToFile(report: Report) {
    // Code to save the report to a file
  }
}

Open Closed Principle (OCP)

The OCP states that a class should be open for extension but closed for modification. This means that you should be able to add new functionality without altering existing code.

class Rectangle {
  width: number;
  height: number;
}

class AreaCalculator {
  calculateRectangleArea(rectangle: Rectangle) {
    return rectangle.width * rectangle.height;
  }
}

To adhere to the OCP, we can introduce an interface and create a new class for calculating the area of a different shape:

interface Shape {
  calculateArea(): number;
}

class Rectangle implements Shape {
  width: number;
  height: number;

  calculateArea() {
    return this.width * this.height;
  }
}

class Circle implements Shape {
  radius: number;

  calculateArea() {
    return Math.PI * this.radius ** 2;
  }
}

This way, if we need to add support for a new shape, we can create a new class that implements the Shape interface without modifying the existing code.

Liskov Substitution Principle (LSP)

The LSP states that objects of a superclass should be replaceable with objects of a subclass without affecting the correctness of the program. This is crucial for maintaining the behavior of the program when extending classes.

class Bird {
  fly() {
    // Code to make the bird fly
  }
}

class Penguin extends Bird {
  fly() {
    // Oops! Penguins can't fly, but still overriding the method
  }
}

In this example, the Penguin class inherits from the Bird class and overrides the fly method, even though penguins can't fly. This violates LSP because the subclass behavior deviates from what's expected in the superclass. To fix this, we can introduce an interface to represent the flying behavior:

interface Flying {
  fly(): void;
}

class Bird implements Flying {
  fly() {
    // Code to make the bird fly
  }
}

class Penguin {
  // Penguins don't implement the Flying interface, as they can't fly
}

By not having Penguin extend Bird, we avoid the LSP violation. Instead, we let Penguin and Bird classes exist independently. If needed, we can introduce interfaces like Swimming for penguins without introducing unexpected behavior into the codebase. This adheres to LSP by ensuring that objects of the superclass can be replaced with objects of the subclass without affecting program correctness.

Interface Segregation Principle (ISP)

The ISP states that a class should not be forced to implement interfaces it does not use. This prevents the creation of “fat” interfaces with methods that are not relevant to all implementing classes.

interface Worker {
  performTask(): void;
  takeBreak(): void;
}

class OfficeWorker implements Worker {
  performTask() {
    // Code for performing office tasks
  }

  takeBreak() {
    // Code for taking a break in the office
  }
}

class Robot implements Worker {
  performTask() {
    // Code for performing automated tasks
  }

  takeBreak() {
    // Oops! Robots don't take breaks in the same way as humans
  }

In this example, both OfficeWorker and Robot are forced to implement the same interface, including the takeBreak method, which doesn't make sense for a Robot. To adhere to the ISP, we can create separate interfaces:

interface TaskPerformable {
  performTask(): void;
}

interface BreakTaker {
  takeBreak(): void;
}

class OfficeWorker implements TaskPerformable, BreakTaker {
  performTask() {
    // Code for performing office tasks
  }

  takeBreak() {
    // Code for taking a break in the office
  }
}

class Robot implements TaskPerformable {
  performTask() {
    // Code for performing automated tasks
  }
  // No takeBreak method, as it's not relevant to robots
}

Now, each class only implements the interfaces with methods relevant to its responsibilities.

Dependency Inversion Principle (DIP)

The DIP states that high-level modules should not depend on low-level modules; both should depend on abstractions. Additionally, abstractions should not depend on details; details should depend on abstractions.

class LightBulb {
  turnOn() {
    // Code to turn on the light bulb
  }

  turnOff() {
    // Code to turn off the light bulb
  }
}

class Switch {
  private bulb: LightBulb;

  constructor(bulb: LightBulb) {
    this.bulb = bulb;
  }

  operate() {
    // Code to operate the switch and the light bulb
  }
}

The code above violates the DIP because the Switch class depends on the concrete implementation of LightBulb. To adhere to the DIP, we can introduce an interface:

interface Switchable {
  turnOn(): void;
  turnOff(): void;
}

class LightBulb implements Switchable {
  turnOn() {
    // Code to turn on the light bulb
  }

  turnOff() {
    // Code to turn off the light bulb
  }
}

class Switch {
  private device: Switchable;

  constructor(device: Switchable) {
    this.device = device;
  }

  operate() {
    // Code to operate the switch and the device
  }
}

Now, the Switch class depends on the Switchable interface, allowing for flexibility in the types of devices it can operate.

Best Practices and Considerations

While embracing SOLID principles, developers should remain mindful of certain practices:

Over-Engineering: Strive for a balance between simplicity and adherence to principles. Overly complex solutions can hinder understanding.
Practicality Over Rigidity: Be pragmatic in applying principles. Prioritize practicality, especially when the cost outweighs the benefits.
Context Matters: Not all principles need uniform application. Tailor their usage based on the specific context and requirements.
Understand the Domain: A deep understanding of the problem domain is crucial for effective application of SOLID principles.
Testing: Write meaningful tests to ensure components work correctly. Tests should complement the principles, not replace them.
Communication: Team-wide agreement on SOLID principles application is crucial for consistency and long-term maintainability.
Continuous Learning: Stay open to new methodologies and technologies. Adapt your approach based on the evolving nature of software development.
Refactoring Skill: Develop and refine your refactoring skills. Knowing when and how to refactor is essential for maintaining a clean codebase.

In conclusion, understanding and applying SOLID principles can significantly improve the quality and maintainability of your code. These principles guide developers in creating software that is modular, extensible, and easy to understand, which is crucial for long-term success in software development.

Navigating System Communication: A Comprehensive Overview

Ewerson Vieira Nascimento — Thu, 01 Aug 2024 23:40:08 +0000

In the dynamic landscape of system communication, developers embark on a journey through various protocols and methodologies to ensure seamless interaction between services. This article aims to provide a nuanced exploration of key concepts, ranging from the foundational principles of synchronous and asynchronous communication to advanced frameworks like gRPC, GraphQL, and the practicalities of Service Discovery using tools like Consul.

Synchronous vs Asynchronous Communication

Synchronous Communication: Real-Time Precision

In synchronous communication, interactions occur in real-time, demanding immediate responses. This approach is crucial for scenarios requiring instant feedback, such as real-time applications or situations where a prompt response is paramount.

Asynchronous Communication: Flexibility with Caution

On the flip side, asynchronous communication introduces flexibility by not mandating an immediate response. While this flexibility is advantageous, it can pose challenges, potentially leading to temporary data inconsistencies. Asynchronous communication finds its utility in scenarios where real-time responses are not imperative.

REST: The Foundation of Web Communication

REST, or Representational State Transfer, stands as a foundational architectural style celebrated for its simplicity and scalability. It adheres to principles like statelessness, cacheability, and a uniform interface.

Maturity Levels (Richardson Maturity Model)

Level 0: The Swamp of POX
Characterized by the use of Plain Old XML (POX) without leveraging the benefits of REST.
Level 1: Using Resources
Resources are identified by URIs, but the interactions are typically limited to CRUD operations.
Level 2: HTTP Verbs
Introduces the use of HTTP verbs for different operations on resources, adding a layer of semantics.
Level 3: HATEOAS (Hypermedia as the Engine of Application State)
The highest level where hypermedia controls are used to navigate the application state.

Crafting a Good REST API

Crafting an effective REST API involves:

Unique URIs:
Distinct Uniform Resource Identifiers (URIs) for each service and exposed item.
HTTP Verbs Utilization:
Employing all HTTP verbs, including caching, for optimized performance.
Relational Links:
Providing hypermedia links for resources, illustrating available actions.

HAL, Collection + JSON, and Siren

Overcoming JSON Limitations:
Recognizing JSON’s lack of a standardized hypermedia linking approach.
HAL (Hypermedia Application Language):
Introducing a standard way to express hyperlinks in JSON through “_links” and “_embedded” objects.
Beyond HAL:
Exploring additional hypermedia formats like Collection + JSON and Siren for extended capabilities.

Fine-Tuning Communication: HTTP Method Negotiation

Understanding HTTP Method Negotiation involves utilizing the HTTP OPTIONS method to inform clients about allowed methods for a specific resource. This enhances discoverability and clarifies the API’s capabilities.

Tailoring Responses: HTTP Content Negotiation

HTTP Content Negotiation allows clients to specify desired response formats via the Accept field, while servers determine request types through the Content-Type header. This negotiation ensures compatibility and seamless communication between clients and servers.

GraphQL: Precision in Querying

GraphQL emerges as a revolutionary paradigm, allowing clients to request precisely the data they need. Developed by Facebook, GraphQL provides a flexible and efficient alternative to traditional REST APIs. Instead of receiving a fixed set of data, clients can specify the structure of the response, minimizing payload size and optimizing frontend performance.

Granular Data Retrieval:
Clients can request only the specific fields they need, avoiding over-fetching or under-fetching of data.
Single Endpoint:
GraphQL typically exposes a single endpoint, simplifying the communication process compared to multiple REST endpoints.
Strongly Typed Schema:
GraphQL APIs are defined by a schema that dictates the types of data that can be queried, providing clarity and structure.
Optimizing Frontend Development:
GraphQL’s flexibility makes it an ideal choice for frontend development, where different views require specific data sets.

To take a more in-depth look at how GraphQL works, check out this project built using Go and gqlgen.

gRPC: A Leap Forward in Communication

gRPC, a framework developed by Google and maintained by CNCF, elevates communication between systems with its emphasis on speed, lightness, and language independence.

When to Embrace gRPC?

Microservices Harmony:
gRPC shines in microservices architectures, fostering efficient communication between distributed components.
Versatility Across Platforms:
Suitable for a wide array of platforms, including mobile devices, backend services, and web browsers.
Automatic Code Generation:
Automatic generation of library code streamlines development across different languages.
Unlocking HTTP/2 Benefits:
Leveraging the HTTP/2 protocol, gRPC supports two-way streaming, enhancing overall performance.

Understanding RPC and Protocol Buffers

Remote Procedure Call (RPC):
Facilitating the execution of procedures on remote servers, bridging communication gaps between distributed components.
Efficiency with Protocol Buffers:
Protocol Buffers, a binary serialization format, outperform JSON in terms of size and speed, making them an efficient choice for data interchange.

HTTP/2: A Leap Forward in Protocol

Exploring HTTP/2 reveals advancements like binary data transfer, multiplexing, server push, and compressed headers. These features collectively enhance efficiency and accelerate communication between clients and servers.

Diverse Communication Formats

Diving into communication formats unveils various modes:

Unary Communication:
Traditional request and response between client and server.
Server Streaming:
Single request with multiple responses, ideal for scenarios with a one-to-many relationship.
Client Streaming:
Multiple requests with a single response, optimal for scenarios with a many-to-one relationship.
Two-Way Streaming:
Enabling multiple requests with multiple responses, fostering real-time bidirectional communication.

Take a look at this Go repository for a practical example using gRPC and Protocol Buffers implementing all the communication formats mentioned above.

Contrasting REST and gRPC

REST:
Text/JSON format, unidirectional communication, higher latency, and no built-in streaming support.
gRPC:
Utilizes Protocol Buffers, supports bidirectional and asynchronous communication, offers lower latency, and enables streaming capabilities.

Service Discovery and Consul: Streamlining System Landscape

Service discovery plays a pivotal role in managing and ensuring machine availability. Consul, a robust tool, combines service discovery, segmentation, and load balancing.

Service Discovery: Navigating the Dynamic Terrain

Service discovery simplifies the dynamic task of locating available machines for communication. In a distributed system, services often change locations, making traditional static configurations impractical. Service discovery automates this process, enhancing flexibility and ensuring that communication channels remain intact.

Dynamic Nature of Services:
Services in a distributed environment can change locations, making dynamic discovery essential for seamless communication.
DNS Resolutions:
Service discovery often relies on DNS resolutions, allowing systems to find and connect with services using human-readable names.

Consul: Orchestrating Seamless Communication

Consul addresses the challenges of dynamic, distributed systems by providing a robust set of features for service discovery, segmentation, and load balancing.

Dynamic Service Registration:
Services register themselves with Consul, enabling dynamic updates as services scale up or down.
Health Checking:
Consul monitors the health of services through configurable health checks, ensuring only healthy instances are utilized.
DNS Resilience:
Leveraging DNS, Consul allows systems to discover and connect with services using human-readable names, enhancing resilience.
Load Balancing:
Consul’s load balancing capabilities distribute traffic across healthy instances, optimizing resource utilization.

Consul’s architecture revolves around three main components, each playing a critical role in orchestrating service discovery and maintaining system integrity.

Agent:
Operating on all cluster nodes, the Agent serves either in Client Mode or Server Mode.
Client:
Registers services locally, performs health checks, and communicates service information to the Server.
Server:
Maintains the cluster state, registers services, manages membership, and handles queries.

Including Consul in Your Service Architecture

Integrating Consul into your service architecture involves:

Deploying Consul Agents:
Install Consul agents on each node in your system, ensuring comprehensive coverage.
Registering Services:
Services register themselves with Consul, providing necessary metadata and health checks.
Service Discovery:
Leverage Consul’s DNS or API for service discovery, allowing systems to locate and communicate with services dynamically.
Load Balancing:
Enable Consul’s built-in load balancing to ensure efficient distribution of traffic across healthy service instances.

This repository shows an example of how Consul can be included in a project.

In this immersive exploration of system communication, we’ve traversed from foundational concepts to advanced frameworks, providing developers with insights to architect robust, scalable, and efficient distributed systems. Each section contributes to a holistic understanding of the intricacies within the ever-evolving landscape of modern software development.