DEV Community: Igor Vorobiov

How I Migrated a Monolith Cron Job to a Serverless Architecture

Igor Vorobiov — Mon, 09 Jun 2025 20:35:08 +0000

A brief background about the app

It’s an app where users upload their data into categories. The app processes that data, runs some additional calculations and aggregations, and stores everything in a database. After that, users can view the resulting data in charts and grids on the website.

There’s also a requirement to capture that data and upload it as CSV files to an S3 bucket — daily, per account and per category.

There are around 20 categories and 10,000 accounts. So in total, the app needs to upload about 200,000 CSV files to S3 every day.

How it was

It all started with a simple cron job that ran a script every day at 5 AM.

The script did 3 things per account and category:

Loaded data from the MySQL database
Prepared the CSV file
Uploaded it to S3

Here’s what it looked like:

Problems 🙄

It’s not scalable — any increase in categories or accounts would linearly increase execution time
It’s not fault tolerant — no built-in retry mechanism or partial success tracking could cause permanent export loss for an entire day
It has a single point of failure — if the machine dies or script crashes mid-way, there’s no recovery or continuation
There’s no proper monitoring — no visibility into what succeeded, failed, or how long it took

How it’s now

Obviously, the previous solution didn’t scale well and needed a fix — fast.

Since we were already using AWS services, I decided to stay within that ecosystem.

I realized that to get the best scalability and fault tolerance, each CSV file had to be prepared and exported separately.

So, I broke the system down into three core components:

Export Scheduler — handles everything related to scheduling
Export Trigger — kicks off the export process for each file
Export Runner — does the actual work: loads the data, prepares the CSV, and uploads it to S3

Here’s what I came up with:

Here’s how the new system works, end to end:

EventBridge kicks things off by emitting a daily export event — this is the trigger that starts the whole export flow.
That event is picked up by the Export Trigger lambda, which is responsible for fetching relevant application data from the database and generating export requests — one for each account and category.
These requests are sent to a queue (or stream), which acts as a buffer and decouples the trigger from the actual export logic.
The Export Runner lambda then processes each export request: it loads the data, prepares the CSV file, and uploads it directly to the S3 bucket.
Meanwhile, logs, metrics, and alarms are pushed to CloudWatch, giving us visibility into what’s happening at every step — useful for monitoring and debugging.

What’s solved 🙂

It’s scalable — each file is handled separately, so the system can easily grow with more categories or accounts without slowing down.
It’s fault tolerant — if a single export fails, it won’t stop the others; failures are isolated and can be retried.
It has no single point of failure — the whole process runs on distributed, managed services, so there’s no risk of a script crashing and killing the job.
It has proper monitoring — with logs, metrics, and alarms, you can track what succeeded, what failed, and how long everything took.
It’s built on AWS-native tools — everything runs on managed services like Lambda, EventBridge, and S3, so there’s no infrastructure to manage or maintain.

Thanks for reading! If you want to stay updated with future posts, hit that follow button. And don’t hesitate to share your ideas or questions in the comments — I’m eager to hear from you!

Dependency Injection vs Service Locator

Igor Vorobiov — Mon, 09 Jun 2025 14:17:42 +0000

Many developers out there don’t see the difference between the dependency injection and the service locator design patterns. Yes, both of them are trying to solve the same problem — increase decoupling. We all know what benefits this give us when it comes to scaling, testing or simply reading the code.

However, how do I know when to use dependency injection and when to use service locator? I would say we should use both of them when appropriate.

If I was asked to choose a single verb that best describes the dependency injection pattern I would choose “to give”. If you think about it, that’s exactly what we achieve with dependency injection after all. We simply give objects to an object.

const window = new Window();
const door = new Door();
const house = new House(window, door);

In this case, we give the window object and the door object to the house object.

On the other hand, if I was asked to describe the service locator pattern with a single verb I would say “to take”. Just think about it. That’s what we do when we use a service locator. We take objects from an object.

const house = container.get(House);

As you can see, we take the house object from the service locator.

In many cases, the dependency injection and the service locator work as a single unit. We might not see it when the things are injected automagically but behind the scene the implementations of dependency injection rely on service locators in order to retrieve actual dependencies.

This is how it might look like somewhere in the code:

const dependencies = dependencyTypes.map(t => container.get(t));

const resolvedInstance = resolveInstance(type, dependencies);

A service locator is pretty easy to implement. All you need is to have ability to get a requested instance by name or id and ability to check whether the requested instance actually exists. Worth to note that a service locator is often called a container. Both things are the same. Both of them are meant to provide instances or services however you prefer to call them. Of course, there’s a difference between a service and an instance when speaking about terms and purposes, but from the technical point of view they are all instances of certain classes.

Here’s a primitive version of a service locator (aka container):

class Container {

  private instances = new Map<string, unknown>();

  get<T>(id: string): T | null {
    return this.instances.has(id) ? (this.instances.get(id) as T) : null;
  }


  has(id: string): boolean {
    return this.instances.has(id);
  }

  register<T>(id: string, instance: T): void {
    this.instances.set(id, instance);
  }
}

const container = new Container();
container.register('house', new House());

// somewhere else

if (container.has('house')) {
  const house = container.get('house');
}

Additionally, I have provided the way to register services.

The implementations of dependency injection usually inject dependencies into objects automatically. All you need is to provide a bit of configuration and that’s all. That’s pretty convenient in many cases, but there are cases when you have to use service locator to avoid the deadlock. This could happen when two instances are depended on each other via constructor. Here’s an example:

class A {

  constructor(b: B) {
    //
  }
}

class B {
  constructor(a: A) {
    //
  }
}

const a = new A(...); // We need B!
const b = new B(...); // We need A!

As you can see, we cannot resolve any of the services because they are depended on each other. We cannot resolve the service A because it requires the service B, and we cannot resolve the service B because it requires the service A. To solve this, we need to retrieve one of the services in lazy-loading way. Meaning that, we should take one of the services from the service locator at the point when the service is actually needed and not in the constructor.

All in all

Hope this article cleared some things up for you and you enjoyed reading it.
You can also check out my service locator @ivorobioff/ioc-container on npm.

The 5 Most Popular Ways APIs Communicate Today

Igor Vorobiov — Mon, 09 Jun 2025 13:43:57 +0000

APIs are essential for enabling communication between software systems. Over time, several popular methods have emerged — each with its own strengths and trade-offs. From the well-established SOAP protocol to modern approaches like GraphQL and gRPC, understanding these popular API communication styles helps developers choose the right tool for their needs. Let’s take a quick look at the five most popular ways APIs communicate today.

SOAP

In short, it’s a protocol that enables developers to invoke methods on remote objects or services. It’s a pretty old dinosaur, both in terms of age and weight. It’s based on XML, which means it carries a lot of text — much more than REST or GraphQL.

It was invented a long time ago and is known for being very secure, strict, and reliable. If you compare them like programming languages, SOAP is like Java, while REST is more like JavaScript.

Because SOAP has been proven over time it’s still used by banks, enterprises, and governments today. There are still many legacy systems relying on it. However, it’s not recommended for new systems where speed and flexibility are important.

So, how it works.

It all starts with WSDL, where all available operations, inputs, outputs, and data types are defined in an XML file. Think of it as a spec for your services. Usually, it’s not written manually but generated from the server-side code.

The client then uses that spec to generate code stubs, allowing developers to call methods on corresponding class instances to communicate with the server.

Behind the scenes though, some XML is created and sent to the server via HTTP requests (in rare cases, there can be other means). The server in turn, parses the retrieved XML and maps its content to a corresponding method on the appropriate class instance, invoking it with the extracted parameters.

The server then serializes the resulting object into XML and sends it back to the client as a response. The client, in turn, deserializes the received XML and continues working with the resulting object.

Overall, developers on both sides don’t work with XML directly — they work with classes, as if the server and client were talking locally rather than remotely thanks to incredible tools available out there. However, this kind of abstraction can cause performance and reliability issues if not handled carefully.

REST

First off, it’s an architectural style, not a protocol or a standard. It leverages the semantics of the HTTP protocol to interact with resources.

A resource is any object or data entity that can be accessed or manipulated via the RESTful API — such as a user, product, order, file, etc.

Each resource is identified by an endpoint, and operations on resources are performed using standard HTTP methods such as GET, POST, PUT, PATCH, and DELETE.

An endpoint is a specific URL path in a RESTful API that clients can send requests to in order to perform actions or retrieve data.

JSON is the most common format for data exchange, although XML and others are also possible.

Typical endpoints follow a resource-oriented structure:

/resources — used to interact with the entire collection of a given resource type (e.g. get all resources, or create a new resource using the HTTP methods such as GET or POST respectively)
/resources/{id} — used to interact with a specific resource identified by its unique ID (e.g. get, delete, update or replace a specific resource using HTTP methods such as GET, DELETE, PATCH or PUT respectively)

It’s also possible to define sub-resources, which represent entities related to or dependent on a parent resource. These are typically accessed by extending the parent resource’s endpoint. For example, /resources/{id}/sub-resources refers to the collection of sub-resources belonging to a specific resource, and /resources/{id}/sub-resources/{sub-id} targets a specific sub-resource.
This nesting can continue further if needed, but deeply nested structures are generally discouraged, as they can become hard to manage and understand.

In contrast to SOAP, RESTful APIs are simple, lightweight, and easy to work with. They can be quickly implemented and tested using any HTTP client, such as Postman or curl.

Thanks to their simplicity, RESTful APIs are widely used on the frontend to fetch data from servers. They are also commonly used for remote communication between backend services.

GraphQL

At its core, GraphQL is a query language for APIs that allows clients to request data in precisely the shape they need. The data is always returned in JSON format.

Unlike REST, which typically exposes multiple endpoints and returns fixed data structures, GraphQL uses a single endpoint (e.g., /graphql) and lets the client specify exactly which fields to include in the response. This approach gives clients greater flexibility and reduces over-fetching or under-fetching of data.

GraphQL is also strongly typed. It requires a schema to be defined in advance, describing all object types, their fields, and the relationships between them. This schema serves multiple purposes:

Validation: The server can verify that incoming queries are well-formed and conform to the schema — ensuring correct field names, types, arguments, variables, and fragments before execution.
Introspection: Clients can query the schema itself to discover available types and operations. This makes it possible to auto-generate documentation and client code — much like reflection in traditional programming languages. Strong typing in GraphQL helps catch errors early, provides predictable responses, and enables powerful tooling like IDE autocompletion and static analysis.

While this may seem like a lot of overhead, the good news is you don’t have to build everything from scratch. There are robust GraphQL libraries and frameworks available for most languages that make it easy to set up a GraphQL server. That said, you’ll still need to implement resolvers — the functions that retrieve data for the requested fields.

Finally, GraphQL is not limited to reading data. It also supports mutations for creating, updating, and deleting data. A mutation is similar to calling a function: you pass in arguments, the server executes the necessary logic (e.g., writing to a database), and a result is returned — often the modified data or a success flag.

GraphQL is great in theory, but in reality it’s not always the case. I’ve been observing that frontends tend to reuse the same query across different places in an app regardless of whether the requested fields are needed or not, and it brings the entire idea of GraphQL into question.

Also, it introduces extra complexity on the server side — you need to carefully manage resolvers, handle query depth, and deal with performance concerns.

On top of that, caching becomes a lot trickier compared to REST, since everything goes through a single endpoint and traditional HTTP caching doesn’t really apply.

WebSocket

It’s a communication protocol that creates a single connection between client and server and keeps it open until one of the parties closes it. It’s perfect for real-time applications like chat apps, live notifications, gaming, and collaborative tools.

It’s quite different from traditional HTTP communication, but it cannot start without HTTP itself. The client and server begin with an HTTP handshake, which is then upgraded to a WebSocket connection.

WebSocket doesn’t enforce any specific data type. It can be any text or binary data. So you are free to choose your own data format, let it be JSON, XML or some text.

A WebSocket URL looks similar to an HTTP URL but uses the ws:// or wss:// scheme, where the latter is secure. It’s also possible to include ports and query parameters, like wss://example.com:8080/chat?token=abc123.

What’s great that WebSocket works over standard ports (80 and 443), so it generally passes through firewalls and proxies. Moreover, it can use existing authentication methods, but it requires custom handling because the protocol does not have built-in support for cookies, headers, or tokens once the connection is established.

Usually, the client sends a token during the initial HTTP handshake. After that, the connection stays open without built-in ways to re-check authentication, so the server must manage access and security if for example a user’s token expires or his permissions change.

All in all, WebSocket is not a replacement for HTTP APIs but a complement, designed for interactive, real-time features. It serves specific use cases and often works alongside traditional HTTP communication.

gRPC

Briefly, gRPC solves the same problem as SOAP but does it much more efficiently with faster, smaller messages and modern technology.

So, what are those technologies?

gRPC uses Protocol Buffers (protobuf), which is a method to define and serialize structured data into a very small, efficient binary format instead of plain text like JSON or XML. This makes messages much smaller and faster to send.

Then, gRPC sends these compact messages over HTTP/2, a modern version of the HTTP protocol that allows multiple messages to be sent simultaneously over a single connection (called multiplexing), supports faster data transfer, and enables features like bi-directional streaming between client and server.

Together, protobuf and HTTP/2 make gRPC communication much faster and more efficient than older approaches.

gRPC is secure because it automatically encrypts all data using TLS, preventing others from spying on or changing the messages. Since it runs over HTTP/2, it also supports token-based authentication — clients include tokens like JWTs or OAuth tokens with each request to prove their identity and permissions, making access control simple and reliable.

Finally, just like with SOAP’s WSDL files, developers rarely work directly with raw gRPC .proto files that define data structures and service methods. Instead, they work with automatically generated code, thanks to powerful tools that handle this process seamlessly.

gRPC is designed with a focus on low latency, scalability, and ease of use, often outperforming traditional REST APIs — especially for internal service-to-service communication — making it ideal for microservices and real-time applications.

However, keep in mind that gRPC has its strengths but can’t fully replace RESTful APIs in frontend environments or similar use cases.

First, browsers don’t natively support all the HTTP/2 features gRPC relies on, so workarounds are needed.

Second, while Protocol Buffers are compact and efficient, they aren’t human-readable, making debugging and manual testing more difficult.

Finally, learning gRPC means understanding HTTP/2, protobufs, and its unique concepts, which can be challenging, especially when working with strictly typed schemas.

In short, APIs use different ways to send and receive data, each with its own strengths. SOAP is secure and reliable for older systems, REST is simple and widely used, GraphQL lets you ask for exactly what you need, WebSocket supports real-time connections, and gRPC is fast and efficient for modern services. Choosing the right one depends on what your project needs.

A Simple Way to Implement Inversion of Control in TypeScript

Igor Vorobiov — Mon, 09 Jun 2025 13:26:08 +0000

What is Inversion of Control (IoC) anyway?

So, practically speaking, it’s when someone else creates and gives me the things I need instead of creating them myself.

Imagine you are a developer who needs tasks to work on. Instead of going out and choosing tasks yourself, a project manager assigns them to you.

This is Inversion of Control in action: You don’t control how the tasks arrive — that responsibility is delegated to someone else. You just focus on doing the work.

Similarly, in software, IoC means that components don’t create or manage their own dependencies — they get them from elsewhere, such as a container or a framework.

This makes the system more decoupled, testable, and flexible, because parts of the system don’t need to know how to set up other parts.

Alright, let’s see it in the code.

⚠️This is terrible code!

class TaskRepository {
  constructor(private db: MySql) { }

  findTasks(query: Query): Task[] {
    return this.db.fetchAll(query).map((row) => Task.create(row))
  }
}

class Backlog {
  private repository: TaskRepository;

  constructor(db: MySql) {
    this.repository = new TaskRepository(db);
  }

  getTasks(): Task[] {
    return this.repository.findTasks(onlyEstemated());
  }
}

class Developer {
  private backlog: Backlog;

  constructor(db: MySql) {
    this.backlog = new Backlog(db);
  }

  work() {
    this.backlog.getTasks().forEach(task => task.done());
  }
}


const developer = new Developer(MySql.connect());

developer.work();

In this example, the database connection is created at the top level and passed manually through every layer. Each component constructs its own dependencies and directly depends on the database. This results in tight coupling and low flexibility — every component is aware of and tied to the database.

If I ever want to change the source of my tasks (e.g., from MySQL to S3), I’ll need to modify multiple components. That’s brittle and hard to maintain.

👍This is a much better approach!

import { Container } from '@ivorobioff/ioc-container';

class TaskRepository {
  private source: Source;

  constructor(container: Container) {
    this.source = container.get('source');
  }

  findTasks(query: Query): Task[] {
    return this.source.fetchAll(query).map((row) => Task.create(row))
  }
}

class Backlog {
  constructor(container: Container) {
    this.repository = container.get(TaskRepository);
  }

  getTasks(): Task[] {
    return this.repository.findTasks(onlyEstemated());
  }
}

class Developer {
  private backlog: Backlog;

  constructor(container: Container) {
    this.backlog = container.get(Backlog);
  }

  work() {
    this.backlog.getTasks().forEach(task => task.done());
  }
}


const container = new Container();

container.registerType(Developer);
container.registerType(Backlog);
container.registerType(TaskRepository);
container.registerFactory('source', () => MySql.connect());

const developer = container.get(Developer);

developer.work();

Here, we’ve introduced an IoC (Inversion of Control) container to manage dependencies. Each component depends only on what it truly needs — nothing more, nothing less. Only TaskRepository is aware of the database. All other components remain agnostic to how tasks are fetched.

This means changing the data source (e.g., switching to S3) requires just one small change during system setup:

container.registerFactory('source', () => S3.connect());

Note: Source is an interface, so any compatible implementation (MySQL, S3, etc.) can be easily swapped in. This decouples your code and makes it far more maintainable and extensible.

💡If you’re looking for a lightweight and flexible IoC container to bring this pattern into your own projects, check out @ivorobioff/ioc-container on npm.

It’s minimal, intuitive, and works well in both backend and frontend environments.

For React developers, there’s also @ivorobioff/ioc-react, a seamless integration that makes dependency injection in React components simple and clean.