DEV Community: Hleb Bandarenka

Mircoservices are Tech Debt... aren't they?

Hleb Bandarenka — Mon, 02 Dec 2024 00:44:55 +0000

As a software engineer, I always believed microservices were the default way to build scalable, modern applications. To me, monoliths seemed like an outdated relic of the past—something to be eliminated in favor of the flexibility and innovation microservices promised.

But recently, I encountered a perspective that challenged this belief. It was from an insightful interview and a subsequent review, which sparked a serious rethink on my part.

I can’t phrase the arguments better than David (the speaker in the interview), so I highly recommend watching it yourself. Here are some key takeaways:

What Microservices Are Really About

Organizational and Dynamic Alignment: Microservices are often more about mirroring how teams and organizations operate than about pure software architecture.

The Challenges of Microservices

These are the challenges we encounter when adopting microservices in an effort to accelerate development:

Increased Network Complexity: Managing communication between services can introduce latency and failure points.
Cross-Team Friction: Dependencies between services often mean dependencies between teams.
Monitoring and Debugging: The distributed nature makes tracking down issues and monitoring the system a lot harder.
Resource Consumption: Each service needs its own runtime, often leading to inefficient resource usage.
System Complexity: A large number of interconnected services increases the cognitive load for developers.
Cascading Failures: A failure in one service can propagate through the system in unpredictable ways.
Silo Effect: Teams can become isolated as they focus only on their service, losing sight of the bigger picture.
Harder Local Development: Running multiple services locally can be cumbersome.
Schema/API Evolution: Updating schemas or APIs requires careful coordination across services.
Distributed Transactions: Managing transactions across services is a notorious challenge.
…and the list goes on.

Is it truly worth it?

Based on the experience of successful companies, adopting microservices can be a powerful way to boost development velocity and, in some cases, the only path to ensure a company’s survival.

The question I pose to you is this: should we always begin with microservices, or is it better to adopt them later as the need arises?

P.S. The scalability benefits commonly attributed to microservices are often more about effective data splitting and sharding than the microservices architecture itself.

The price of the erosion architecture or "The Good, the Bad, and the Ugly"

Hleb Bandarenka — Fri, 15 Mar 2024 02:40:24 +0000

Today, instead of diving into another technical article, I'd like to share some thoughts on architecture. This short post encapsulates ideas that have shaped my career journey.

Let's Rock 🚀🎸

Many folks recognize the importance of having architecture.

Whenever someone mentions this idea, they often refer to Martin Fowler's article (Is High Quality Software Worth the Cost?) where he demonstrates that adding new features to high-quality code is not only easier but also cheaper (I would even say more enjoyable). Martin emphasizes that quality code adheres to certain architectural principles.
And, of course, there's the graph that illustrates this key concept.

But I've always wondered, what's the cost of having the erosion architecture?
Let me break it down. Erosion architecture is one that doesn't match the current business needs and adds unnecessary complications.

Still not clear? 🤯
Let me show you with an example:
Imagine we're building an online shop, starting with car sales. As we plan the application's architecture, we need to consider its future growth. Which direction should we anticipate?

If our focus remains on selling cars, we'll need more specific filters like brands, engine types, and number of wheels. Our architecture should allow for easy addition of new car characteristics.
Alternatively, if we plan to expand our business to include bikes, trucks, and airplanes, we won't delve as deeply into each product. Instead, we'll introduce an Enum with product types to accommodate this broader range.

Option 1



interface Repository1 {
  getCarByBrand(brand: string): Car[];
  getCarByModel(model: string): Car[];
  getCarByYear(year: number): Car[];
  getCarByColor(color: string): Car[];
  // ... other methods
}

interface Car {
  brand: string;
  model: string;
  year: number;
  color: string;
  price: number;
  owner: string;
}

Option 2



interface Repository2 {
  getAllVehicleTypes(): string[];
  getVehicleByType(type: string): Vehicle[];
}

interface Vehicle {
  description: string;
  price: number;
  type: string;
}

As you can see, both of these solutions make sense, but they represent two different axes of change. Choosing the wrong one could result in increased effort to support the architecture and add new functionality that doesn't align with it. Instead of speeding us up, the architecture could slow us down.

Unfortunately, this scenario is quite common, especially in fast growing companies. A team might choose a solution, but later, the business decides to drastically change its model. However, there isn't enough time to adapt the architecture accordingly. Whether we call it tech debt, bad quality code, or cutting corners, the result is the same: the architecture doesn't align with the current business needs.

Since everyone appreciates graphs, let's visualize how problematic this situation can be.

I still believe that having some architecture even an erosion one is better than having no architecture at all. Even if the architecture doesn't facilitate quick development, it at least ensures that everyone follows the same pattern.

Conclusion 🤔

Let it be messy but consistent

Exploring ts-mockito: An Alternative Mocking Library for Node.js Unit Testing

Hleb Bandarenka — Thu, 08 Feb 2024 00:35:02 +0000

Who should read it?

If you've transitioned from the Java/C# realm to NodeJS and find comfort in the reliability of traditional OOP practices, but struggle with writing unit tests and mocking your classes, this article is for you. Jest and Sinon are powerful tools, but may not seamlessly integrate with classes, TypeScript, or Dependency Injection. Curious about alternatives? Enter ts-mockito. 🎉🥳

Prerequisites

OOP language (Java/C#)
Unit tests
Jest/Sinon

Let's rock 🚀🎸

So, like me, you probably prefer a good night's sleep over deploying hotfixes in the wee hours of the morning. And to ensure that luxury, you understand the importance of having robust test coverage.

Naturally, you want to cover all possible scenarios, from the happy paths to the not-so-happy ones, in your code. And you want to do it effortlessly.

However, the reality is that popular libraries like Jest and Sinon aren't exactly tailored for mock classes and TypeScript interfaces. Mocking with them can be a tedious and time-consuming process.

So, I started searching for something like Mockito from the Java world.
What did I need?

I wanted to easily mock all methods of classes and interfaces.
It had to work well with TypeScript, so my IDE could help me with auto-complete.
I also wanted a straightforward verification function for asserts.

And then I discovered - ts-mockito 📦. The name says it all - it's a mix of TypeScript and Mockito.
Sounds exciting, doesn't it? Let's give it a try and see what it can do:

Application 🧩

Imagine we have an application where an employee wants to send a message to their own department.

Following the MVC pattern, we'll have:

2 repositories (one for employees and one for departments)
2 services (one for departments and one for notifications)

I will show just the main DepartmentService that we will test.
(Github)

export class DepartmentService {
  constructor(
    private readonly employeeRepository: EmployeeRepository,
    private readonly departmentRepository: DepartmentRepository,
    private readonly serviceA: NotificationService
  ) {}

  public async sendMessage(input: InputData) {
    try {
      const employee = await this.employeeRepository.getEmployee(input.employeeId);
      const department = await this.departmentRepository.getDepartment(
        employee.departmentId
      );
      await this.serviceA.sendMessage(department, employee, input.message);
    } catch (e) {
      if (e instanceof Error) {
        await this.serviceA.sendAlert(input.employeeId, e.message);
      }
    }
  }
}

export type InputData = {
  employeeId: number;
  message: string;
};

Now, let's take a look at the same unit tests written using Jest and ts-mockito.

Jest

describe("Department Service", () => {
  let employeeRepository: jest.Mocked<EmployeeRepository>;
  let departmentRepository: jest.Mocked<DepartmentRepository>;
  let notificationService: jest.Mocked<NotificationService>;
  let departmentService: DepartmentService;

  beforeEach(() => {
    employeeRepository = {
      getEmployee: jest.fn(),
      saveEmployee: jest.fn(),
      updateEmployee: jest.fn(),
      deleteEmployee: jest.fn(),
    } as jest.Mocked<EmployeeRepository>;
    departmentRepository = {
      getDepartment: jest.fn(),
      saveDepartment: jest.fn(),
      updateDepartment: jest.fn(),
      deleteDepartment: jest.fn(),
    } as jest.Mocked<DepartmentRepository>;
    notificationService = {
      sendMessage: jest.fn(),
      sendAlert: jest.fn(),
    } as jest.Mocked<NotificationService>;
    departmentService = new DepartmentService(
      employeeRepository,
      departmentRepository,
      notificationService
    );
  });

  it("should send a message when employee and department exist", async () => {
    // given
    const departmentId = 94323;
    const employeeId = 2342;
    const employee: Employee = {
      id: employeeId,
      name: "John Doe",
      departmentId,
    };
    const department: Department = { id: departmentId, name: "Department" };
    const input = { employeeId: employeeId, message: "Hello" };

    employeeRepository.getEmployee.mockResolvedValueOnce(employee);
    departmentRepository.getDepartment.mockResolvedValueOnce(department);

    // when
    await departmentService.sendMessage(input);

    // then
    expect(employeeRepository.getEmployee).toHaveBeenCalledWith(
      input.employeeId
    );
    expect(departmentRepository.getDepartment).toHaveBeenCalledWith(
      departmentId
    );
    expect(notificationService.sendMessage).toHaveBeenCalledWith(
      department,
      employee,
      input.message
    );
    expect(notificationService.sendAlert).not.toHaveBeenCalled();
  });

  it("should send an alert when an error occurs", async () => {
    // given
    const employeeId = 9834;
    const input = { employeeId: employeeId, message: "Hello" };
    const errorMessage = "Something went wrong";
    const error = new Error(errorMessage);

    employeeRepository.getEmployee.mockRejectedValueOnce(error);

    // when
    await departmentService.sendMessage(input);

    // then
    expect(notificationService.sendAlert).toHaveBeenCalledWith(
      employeeId,
      errorMessage
    );
    expect(notificationService.sendMessage).not.toHaveBeenCalled();
  });
});

ts-mockito

import { mock, instance, when, verify, _ } from "@johanblumenberg/ts-mockito";

describe("Department Service", () => {
  let employeeRepository: EmployeeRepository;
  let departmentRepository: DepartmentRepository;
  let notificationService: NotificationService;
  let departmentService: DepartmentService;

  beforeEach(() => {
    employeeRepository = mock(EmployeeRepository);
    departmentRepository = mock(DepartmentRepository);
    notificationService = mock(NotificationService);
    departmentService = new DepartmentService(
      instance(employeeRepository),
      instance(departmentRepository),
      instance(notificationService)
    );
  });

  it("should send a message when employee and department exist", async () => {
    // given
    const departmentId = 94323;
    const employeeId = 2342;
    const employee: Employee = {
      id: employeeId,
      name: "John Doe",
      departmentId,
    };
    const department: Department = { id: departmentId, name: "Department" };
    const input = { employeeId: employeeId, message: "Hello" };

    when(employeeRepository.getEmployee(employeeId)).thenResolve(employee);
    when(departmentRepository.getDepartment(departmentId)).thenResolve(
      department
    );

    // when
    await departmentService.sendMessage(input);

    // then
    verify(employeeRepository.getEmployee(input.employeeId)).called();
    verify(departmentRepository.getDepartment(departmentId)).called();
    verify(
      notificationService.sendMessage(department, employee, input.message)
    ).called();
    verify(notificationService.sendAlert(_, _)).never();
  });

  it("should send an alert when an error occurs", async () => {
    // given
    const employeeId = 9834;
    const input = { employeeId: employeeId, message: "Hello" };
    const errorMessage = "Something went wrong";
    const error = new Error(errorMessage);

    when(employeeRepository.getEmployee(employeeId)).thenThrow(error);

    // when
    await departmentService.sendMessage(input);

    // then
    verify(notificationService.sendAlert(employeeId, errorMessage)).once();
    verify(notificationService.sendMessage(_, _, _)).never();
  });
});

Comparison results ⚔️⚔️⚔️

If we count the lines, we'll notice that ts-mockito is 20% shorter.
Also, I intentionally added more methods in the Repositories to demonstrate that Jest requires us to specify all methods manually and update the mocks every time a new method is added. Just image that you will have to update tests that are not related to a new functionality.
Additionally, autocomplete doesn't work for parameters in expect...toHaveBeenCalledWith with Jest.

Warning ⚠️

You may have noticed that instead of the official ts-mockito library, I imported its fork @johanblumenberg/ts-mockito. The reason for this is that ts-mockito hasn't received any new commits for the last 3 years. Johan Blumenberg, a developer who made numerous suggestions and pull requests for the library, decided to fork it and fix all the annoying bugs while the official version remains unupdated.

Conclusion

Despite some nuances, my team and I have decided to use forked ts-mockito for our unit tests. And I believe that this library will make your life as a developer much easier.

P.S. 🤔

You may consider to use @typestrong/ts-mockito as forked alternative to ts-mockito

Delving into the Black Magic of GraphQL DataLoader! 🌌✨

Hleb Bandarenka — Tue, 16 Jan 2024 14:57:00 +0000

Who should read this?

If you've got GraphQL experience, encountered the N+1 problem, and used DataLoader to solve it but are still unclear on how it works, you're in the right spot.

Prerequisites:

Familiarity with the DataLoader pattern
Understanding of the Event Loop

Let's rock 🚀🤘🎸

When I began working with GraphQL, I had concerns about the N+1 query problem. In my research, I came across the DataLoader pattern and its implementation on GitHub. While I explored various examples of its usage, I still struggled to grasp how it operates internally. Join me in delving a bit deeper into GraphQL DataLoader! :)

I hope my readers are already familiar with how the EventLoop works. If not, I highly recommend checking out this insightful series of articles with excellent visualizations here.

For our current discussion, pay special attention to Part 2 - Bonus experiment. This experiment demonstrates that the nextTick operation triggered inside a Promise will execute after all other Promises have been completed.

Why is this crucial? ❗️❗️❗️

This experiment illustrates that the nextTick operation triggered inside a Promise will be executed after all other Promises are completed. The emphasis on this aspect is crucial because DataLoader leverages this peculiarity to perform its magic in the enqueuePostPromiseJob. 🎩✨

code

// `enqueuePostPromiseJob` function
...
if (!resolvedPromise) {
  resolvedPromise = Promise.resolve();
}
resolvedPromise.then(() => {
  process.nextTick(fn);
});
...

When you create a DataLoader, you provide a BatchLoadFn as a constructor argument. The enqueuePostPromiseJob serves as the default batchScheduleFn, responsible for scheduling when the BatchLoadFn (the fn argument is dispathBatch -> BatchLoadFn) should be invoked.

This process kicks off when you first invoke the load method on DataLoader. That's when enqueuePostPromiseJob starts its job. 🤯

Did my message make sense? I'm a bit unclear myself.
I hope the schema I provided will help clarify what I wanted to say.

What does it mean for us? 🤔

It signifies that DataLoader gathers all IDs passed during synchronous invocation, including those within nextTick and Promises, even if the Promise IDs were defined within another Promise. However, it doesn't include nextTick IDs added inside a Promise.

P.S. This is true if the initial load was invoked synchronously; otherwise, all IDs will be collected.

Code on Github

index.js

const DataLoader = require("dataloader");
const db = require("./database");

// Create a batch loading function
async function batchLoadFunction(ids) {
  const results = await db.findAll(ids);

  // Return the results in the same order as the keys
  return ids.map((key) => results.find((result) => result.id === key));
}

// Create a new DataLoader instance
const dataLoader = new DataLoader(batchLoadFunction);

// Use the DataLoader to load data
(async () => {
  // 1. Sync calls
  const p1 = dataLoader.load(1);
  const p2 = dataLoader.load(2);
  Promise.all([p1, p2]).then((results) => {
    console.log(results);
  });

  // 2. Next tick calls
  process.nextTick(() => {
    console.log("next tick");
    const p3 = dataLoader.load(3);
    const p4 = dataLoader.load(4);
    Promise.all([p3, p4]).then((results) => {
      console.log(results);
    });
  });

  // 3. Promise calls
  Promise.resolve().then(() => {
    console.log("promise");
    const p5 = dataLoader.load(5);
    const p6 = dataLoader.load(6);
    Promise.all([p5, p6]).then((results) => {
      console.log(results);
    });

    // 4. Next tick inside promise
    process.nextTick(() => {
      console.log("next tick inside promise");
      const p7 = dataLoader.load(7);
      const p8 = dataLoader.load(8);
      Promise.all([p7, p8]).then((results) => {
        console.log(results);
      });
    });

    // 5. Promise inside promise
    Promise.resolve().then(() => {
      console.log("promise inside promise");
      const p9 = dataLoader.load(9);
      const p10 = dataLoader.load(10);
      Promise.all([p9, p10]).then((results) => {
        console.log(results);
      });
    });
  });
})();

Result:

next tick
promise
promise inside promise resolve handle
Querying ids: 1,2,3,4,5,6,9,10
next tick inside promise resolve handle
[ { id: 1, name: 'John', age: 25 }, { id: 2, name: 'Jane', age: 30 } ]
[ { id: 3, name: 'Bob', age: 35 }, { id: 4, name: 'Alice', age: 28 } ]
[ { id: 5, name: 'Mike', age: 32 }, { id: 6, name: 'Sarah', age: 27 } ]
[ { id: 9, name: 'Michael', age: 31 }, { id: 10, name: 'Sophia', age: 26 } ]
Querying ids: 7,8
[ { id: 7, name: 'David', age: 33 }, { id: 8, name: 'Emily', age: 29 } ]

Clearly, the next tick inside promise was triggered after querying the BatchLoadFn. Consequently, the IDs from that nextTick joined the second invocation of BatchLoadFn.

How can we use it?

Soooo, if we incorporate DataLoader within Promises, everything will function as anticipated. Now, we have a clear understanding of the reasons behind it. 😊🎉

I hope this post has shed some light on the subject. If you're keen on a more in-depth understanding, I encourage you to take a look at the source code yourself. At the very least, you now have a solid foundation of understanding.

Bonus

How does this pattern operate in other languages, like Java? Unfortunately, due to Java's threading mechanism, where all threads share equal priority, the solution is not as elegant and necessitates manual dispatching.

dataloader.load("A");
dataloader.load("B");
dataloader.load("A");

dataloader.dispatch(); // in Java you have to manually invoke `dispatch` function

Apollo GraphQL products for dummies

Hleb Bandarenka — Thu, 28 Dec 2023 20:05:04 +0000

What question does this article answer?

This article aims to help you understand what Apollo products are available and distinguish between the free and paid options.

Prerequisites

Familiarity with GraphQL
Awareness of Apollo Server and Federation.

Let's rock

If you're new to GraphQL, you've probably heard of Apollo GraphQL. They're a company that makes tools for GraphQL, some of which are free and some you have to pay for. I was confused at first about which ones to use and if I had to pay. In this article, I'll share what I figured out and my thoughts on Apollo's tools.

Before we dive into the products, let's talk about Apollo's standout feature - Apollo Federation. The tricky part for me was understanding what it actually is. Even the official documentation starts with the problem it solves, but not a clear definition. Some say it's an architecture model, but it's way more than just a diagram. It expands the GraphQL schema and introduces new terms like subgraph, supergraph, router, and gateway...

So, what is Apollo Federation?
I would say it is an implementation of GraphQL Federation.
Alright, what is GraphQL Federation then?
Think of it like an API Gateway that brings together all the microservices using GraphQL, similar to how an API Gateway combines microservices with REST APIs into one place.

In the context of an API Gateway, Apollo Federation needs a dedicated service as the entry point for clients. Apollo provides 2 options for that:

Apollo Gateway
Apollo Router

What is the difference between Apollo Gateway and Router?

Apollo Gateway is essentially Apollo Server just with a slightly different setting, written in Typescript.
P.S. Apollo Server is an open-source, spec-compliant GraphQL server

Apollo Router is suggested for production. It's written in Rust, potentially offering better performance, but making changes may demand more effort from your team.

The great news is that all the technologies I've mentioned - Apollo Federation, Apollo Server/Gateway, and Apollo Router - are free to use.

Anything else free for us?

Apollo provides free GraphQL clients, whether you're using Federation or not, there's no difference for the clients. These clients include an internal cache to lighten the load on your application.
Example: React Client

Anything more?

Certainly! There are two tools to assist with development:

GraphQL Playground (deprecated)
Apollo Sandbox

You can think of them like Swagger or Postman (btw, you can use Postman instead of all these tools).

Alright, what about the not-so-free stuff?

Firstly, there's the Cloud Router from Apollo, which eliminates the need for a separate service to handle requests, but it comes with a cost based on the number of requests. Also, it provides the benefit of collecting metrics and statistics.

The second paid product is Managed Federation. It consist of Schema Registry (a service that combines subgraphs into a supergraph, ensuring compatibility) and Uplink (a service that stores the current supergraph).
Cloud and self-hosted Routers seamlessly work with Managed Federation, fetching a new supergraph automatically unlike the free solutions that require a restart after updating a subgraph.

Apollo Studio, a web UI, lets you manage these paid products. To use the studio, create a GraphOS account and choose a subscription.

So let's wrap up