Forem: Dmitrii Nefedov

Browser API: URLPattern — A Modern Way to Compare URLs

Dmitrii Nefedov — Fri, 14 Nov 2025 09:34:42 +0000

Hello, web developers!

I want to quickly introduce a really cool and relatively new browser API that can be incredibly useful for frontend developers. We’re talking about URLPattern.

Official documentation

What is it?

This API allows you to quickly parse and match URLs against predefined patterns

URLPattern gives you access to:

Path parameters
Hostname parameters
Port
Protocol
Search parameters
Hash
Basically, everything in a URL

How to use it?

Create a pattern using the new URLPattern() constructor:

const pattern = new URLPattern(...);

The object has two main methods:

test(url)

Returns a boolean — whether the URL matches the pattern.

exec(url)

Returns an object with extracted parameters from the URL.

Example of the result structure:

{
  hash: { groups: { 0: '' }, input: '' },
  hostname: { groups: { 0: 'domain.com' }, input: 'domain.com' },
  inputs: ['https://domain.com/path/1'],
  password: { groups: { 0: '' }, input: '' },
  pathname: { groups: { id: '1' }, input: '/path/1' },
  port: { groups: { 0: '' }, input: '' },
  protocol: { groups: { 0: 'https' }, input: 'https' },
  search: { groups: { 0: '' }, input: '' },
  username: { groups: { 0: '' }, input: '' }
}

Usage Examples

Named Parameters

const pattern = new URLPattern({ pathname: "/path/:id" });

pattern.test('https://domain.com/path/1');
true

pattern.test('https://domain.com/path/sub_path/1');
false

pattern.test('https://domain.com/path');
false

pattern.exec('https://domain.com/path/1').pathname.groups;
{ id: '1' }

Wildcard (*)

const pattern = new URLPattern({ pathname: "/path/*" });

pattern.test('https://domain.com/path/1');
true

pattern.test('https://domain.com/path/sub_path/1');
true

pattern.test('https://domain.com/path');
false

pattern.exec('https://domain.com/path/1').pathname.groups;
{ 0: '1' }

pattern.exec('https://domain.com/path/sub_path/1').pathname.groups;
{ 0: 'sub_path/1' }

Optional Segment ({/sub_path}?)

const pattern = new URLPattern({ pathname: "/path{/sub_path}?" });

pattern.test('https://domain.com/path/1');
false

pattern.test('https://domain.com/path/sub_path');
true

pattern.test('https://domain.com/path/sub_path/1');
false

pattern.test('https://domain.com/path');
true

pattern.exec('https://domain.com/path/1').pathname.groups;
null

pattern.exec('https://domain.com/path/sub_path/1').pathname.groups;
null

pattern.exec('https://domain.com/path/sub_path').pathname.groups;
{}

Hostname + Pathname

const pattern = new URLPattern({
  hostname: ":sub.domain.com",
  pathname: "/path/:id"
});

pattern.test("https://api.domain.com/path/42");
true

pattern.test("https://api.domain.com/path");
false

pattern.test("https://other.other_domain.com/path/42");
false

pattern.exec("https://api.domain.com/path/42").pathname.groups;
{ id: '42' }

pattern.exec("https://api.domain.com/path/42").hostname.groups;
{ sub: 'api' }

Which URL parts can you match?

In the URLPattern constructor, you can use the following properties:

protocol
hostname
port
pathname
search
hash

Conclusion

URLPattern is a very convenient API for working with URLs in the browser. For obvious reasons, it has some limitations in older browsers, but for modern web applications, it provides a simple and concise way to parse and match URLs.

Personally, I’m very glad this API exists — it really simplifies the life of frontend developers.

Thank you all for your time and attention!

Frontend Architecture. Result Type Pattern

Dmitrii Nefedov — Tue, 11 Nov 2025 16:00:00 +0000

Hi everyone! Today I want to talk (or remind) about a really cool and practical pattern called the Result type. I think this article will be short, but interesting for those who haven’t worked with this approach before and are tired of callback hell and unexpected exceptions when developing web applications.

What is the pattern about?

It’s simple — stop using exceptions for normal business logic.

Exceptions are meant for truly exceptional cases, situations that are not expected during normal program execution. But in many applications, we often see business logic built on exceptions, which is actually an anti-pattern. If an error is likely to happen during normal business logic, it is not an exceptional case by definition.

Today, we’ll look at a cleaner alternative from the perspective of business logic — the Result type.

Implementation in TypeScript

I want to show the full implementation first and explain it below. I think this makes it easier to understand.

type SuccessResult<P> = {
  success: true;
  payload: P;
};

type ErrorResult<E> = {
  success: false;
  error: E;
};

export type Result<P, E> = SuccessResult<P> | ErrorResult<E>;

const success = <P>(payload: P): Result<P, never> => {
  return { success: true, payload };
};

const error = <E>(error: E): Result<never, E> => {
  return { success: false, error };
};

export const Result = {
  success,
  error,
};

I created two separate types (SuccessResult and ErrorResult) with different success flags, and a union type Result that we export.

I also made two factory functions to simplify creating Result in its different variations - success and error functions.

enum DOMAIN_ERROR {
  NOT_ENOUGH_BALANCE = "NOT_ENOUGH_BALANCE",
}

type Payload = {
  transactionId: string;
};

const transferMoney = (): Result<Payload, DOMAIN_ERROR> => {
  const random = Math.random();

  if (random > 0.5) {
    // Error: not enough balance
    return Result.error<DOMAIN_ERROR>(DOMAIN_ERROR.NOT_ENOUGH_BALANCE);
  }

  // Success
  return Result.success<Payload>({ transactionId: "tx456" });
};

const transferResult = transferMoney();

if (transferResult.success) {
  console.log(transferResult.payload);
} else {
  console.log(transferResult.error);
}

In this example, we simulate a money transfer. The function transferMoney can either succeed and return a transaction ID, or fail if there is not enough balance. By returning a Result type instead of throwing an exception, we make it explicit which outcome happened.

The if (transferResult.success) check lets TypeScript narrow the type, so inside the if block we know for sure that payload exists, and inside the else block we know that error exists. This makes handling both success and error cases safe and predictable.

Advantages of this approach

No exceptions: type safety is always preserved, and there are no hidden cases or unexpected values.
TypeScript ensures error handling: without checking success, we cannot access payload. This makes it easier to see where errors may occur and handle them properly.
Clear list of errors: you can use enums or more complex types/classes, giving you full control over error information and format.
Readable business logic: the flow is obvious, especially useful in large applications.

Conclusion

I really like this pattern and recommend using it based on many years of web development experience. It gives more control over runtime behavior and fits well with architectures like Domain-driven design. Unit testing also becomes simpler and clearer.

Yes, you have to write a bit more code and always check success before accessing payload instead of just throwing an exception, but our job as developers is not to write less code, but to write it well, right?

What do you think — is it worth using this pattern in your projects? Leave your comments :) I would love any feedback!

And thanks for your time 🙏

Frontend Architecture. Layers & Domain Mindset

Dmitrii Nefedov — Tue, 04 Nov 2025 16:00:00 +0000

Welcome! We continue our series of articles about frontend architecture.

Mindset and Architectural Thinking

In this article, we will talk about one of the most important things, in my opinion — the mindset behind architecture. What do I mean by that? It’s the understanding of what our job as developers really is and how we plan to do it.

From my experience, this is one of the most underrated and missed aspects of software development. Most projects I’ve seen were developed in a “whatever works” way. You take some boilerplate template, start adding folders and files — that’s your project initialization — and then every problem is solved in whatever way the current developer thinks of (or whatever the AI suggests).

This approach leads only to chaos after a few years, where only people who have worked in the company long enough can understand what, when, and how something was developed.

The Alternative — Designing Systems in Advance

The alternative is to design systems in advance. For me, this is what application architecture means:

The idea of how we build a project and how we approach solving problems through code

P.S. I don’t believe there is a universal template for good architecture. There are many books with elegant and well-explained approaches, but the real world is chaotic, and it’s often hard to follow guides or patterns strictly. Over time, I came to the idea: Good architecture is the one that makes it easy to evolve the project. And that depends on the specific team, people, and company culture. Sometimes even not-so-perfect patterns (and sometimes anti-patterns) work better than “proper” ones — just because people understand them and are comfortable using them. Meanwhile, “best practices” can bring more confusion and problems if the team cannot fully understand them. And that’s totally fine.

My Approach to Architecture

So, here are my thoughts and my approach to architecture — in general, and in frontend specifically.

First of all, I really like DDD (Domain-Driven Design) model. For me, these are the most flexible and logical patterns, because I clearly understand where in the system I need to make changes to keep my code structured and reliable.

P.S. I’ll try to describe everything in simple and practical language, as I see it in my everyday work. You can always read the official books if you want more theory and details.

I’ll start with an example and share a few thoughts, and then explain what benefits this approach brings.

Domain-Driven Design

DDD are slightly different implementations of the same idea — splitting the application into layers, each with a clear responsibility.

This separation helps us:

Keep control and confidence in our code through the whole project lifecycle,
Reduce development and maintenance costs as the project grows,
And minimize the number of bugs caused by complexity.

In practice, this means a structured organization of layers and well-defined interaction between them.

Project Structure

Besides DDD, I usually organize my projects according to the Screaming Architecture principle (from Robert Martin’s "Clean Architecture" book).

For example, I created three modules — cart, catalog, and user — to show the structure:

src
 ├─ modules
   ├─ catalog
   ├─ users
   └─ cart

Also, from my experience, I usually need two shared modules (I mark them with _ prefix for visual separation):

_shared — code for shared functionality between modules (for example, basic React components or hooks)
_core — common interfaces and base classes used by the whole application (I’ll describe this in the next articles)

src
 ├─ modules
   ├─ _core
   ├─ _shared
   ├─ catalog
   ├─ users
   └─ cart

Each module contains the classic three abstraction layers:

src
 ├─ modules
   ├─ _core
     ├─ domain
     ├─ infrastructure
     └─ presentation
   ├─ _shared
     ├─ domain
     ├─ infrastructure
     └─ presentation
   ├─ catalog
     ├─ domain
     ├─ infrastructure
     └─ presentation
   ├─ users
     ├─ domain
     ├─ infrastructure
     └─ presentation
   └─ cart
     ├─ domain
     ├─ infrastructure
     └─ presentation

Interaction Between Layers Inside a Module

The core of our system is the Domain layer in each module. It contains everything related to business logic. This code should be as independent as possible from frameworks and libraries, because the most stable applications are those where the business logic doesn’t depend on external tools. And the most reliable way to achieve that — is to avoid dependencies at all :)

Infrastructure — data access layer (it can be a database, backend API, localStorage, cookies, etc.)
Presentation — user interaction layer (UI components, React hooks, etc.; for backend — controllers)

Dependency Direction

The interaction between layers looks like this:

Infrastructure <- Domain -> Presentation

It’s controlled through contracts — TypeScript interfaces and types.

This is the most important part of this article, because this is the mindset you should follow when working on any task. For every new feature, you should split it into different layers and think about which part belongs where and why. For every bug, you should ask on which layer it appears and where it’s best to fix it.

Trade-offs and Benefits

This approach usually slows down development at the start of a project,
but it gives you many advantages later:

Business logic changes are centralized and isolated from UI components.
API interaction is isolated in the Infrastructure layer, so I can change it without fear of breaking business logic.
The same with UI — changes in Presentation can’t break business logic.
I don’t waste time deciding “where should I put this code”, so development becomes more structured and focused on real business needs.

And that’s not the full list. There’s one more interesting thing — the business side.

Sometimes we have to write not-so-perfect code under deadlines or pressure. But I noticed something unexpected (by my experience):

Business people are usually okay with spending more time and money early if they understand that it will save a lot more in the future.

Interaction Between Modules

Ideally, every module (except shared ones like _shared and _core) should be independent from others. All interfaces should be generic — this gives maximum flexibility and reliability. But in the real world, especially in frontend, it’s hard to reach full isolation. Usually, pages combine several modules at once. So I don’t recommend setting strict limitations here.

If you have better ideas — I’d love to read them in the comments 🙏

There’s only one rule I always follow (and I think it’s clear): never import business logic modules into shared ones (_shared or _core).

Conclusion

Architecture is not just about folder names or fancy diagrams — it’s about how we think when we write code. It’s a way to organize not only our projects, but also our mindset as developers.

The main goal of layering and clear structure is not to make things “perfect,” but to make them manageable, predictable, and easy to grow. When every team member understands where each piece of logic belongs, development becomes faster, cleaner, and less stressful.

Yes, this approach takes more effort at the beginning. But in return, it gives stability, confidence, and freedom to evolve your product without fear of breaking everything.

What’s Next

That’s all for now.

In the next article, I’ll describe one of the _core classes I actively use — Result, and explain this pattern in more detail.

A tiny CSS trick that speeds up long pages..

Dmitrii Nefedov — Mon, 27 Oct 2025 11:08:54 +0000

Dmitrii Nefedov

Oct 27 '25

Content-visibility: Boost Amazon product grid (or any long grid) performance with one CSS property

#webdev #frontend #css #webperf

Comments

2 min read

Content-visibility: Boost Amazon product grid (or any long grid) performance with one CSS property

Dmitrii Nefedov — Mon, 27 Oct 2025 11:05:40 +0000

Hi everyone!

Today I want to show you a small rendering optimization that can be useful for long pages — especially if you have something like a product grid: many complex but similar blocks on a page, and most of them are not visible at first (you need to scroll).

This trick is small, but very cheap — it takes only a few seconds to apply, and your page can render a bit faster.

What are we talking about?

We will talk about a CSS property called content-visibility.

In short:

content-visibility tells the browser not to render elements that are outside the viewport until they are needed (for example, when the user scrolls to them). It’s like a simple “render lazy-loading” for layout and paint.
This property is usually used together with contain-intrinsic-size to indicate the expected size of a block to the browser. This property allows the browser to defer rendering content that is not currently visible on the screen.

I first learned about it from an article on web.dev a few years ago, and I thought it was awesome!
At that time, I worked for a big e-commerce company with a heavy product grid.
We were always working on performance improvements, because many studies show that page loading and rendering speed have a direct impact on conversion rates — and conversions mean real money and company reputation.

P.S. I don’t pretend to reveal something new — I just want to remind the community that this property exists, and it’s super easy to use

What I did

Just a few simple steps

Opened an Amazon search page, for example: https://www.amazon.com/s?k=Nike
Measured performance — focusing on painting and rendering

Overwrote one CSS rule and added two properties:

..s-result-item  {
  content-visibility: auto;
  contain-intrinsic-size: 250px 600px; // This is exact size for every grid item on my screen
}

Ran the performance test again.

That’s it!

Results (depending on the device and browser)

Rendering became about ~15% faster.
Painting became about ~27% faster.

No magic — the browser just doesn’t render what is not visible yet.

Conclusion

If you have a long page with many repeated blocks — try using content-visibility.
It takes only seconds, but the performance win can be noticeable.

P.S.Thanks everyone for reading! If this article was useful for you, or just like content about speeding up web applications, leave a reaction or a comment — I’ll make sure to share more posts on this topic!

[Boost]

Dmitrii Nefedov — Sat, 25 Oct 2025 22:30:02 +0000

Simple build and run NodeJS application on AWS (Lambda) using Architect (arc.codes)

Dmitrii Nefedov ・ Oct 25

#webdev #programming #node #aws

Simple build and run NodeJS application on AWS (Lambda) using Architect (arc.codes)

Dmitrii Nefedov — Sat, 25 Oct 2025 02:02:37 +0000

Hey everyone! 👋
In this article, I’ll show how to easily create and run a backend on NodeJS in AWS Lambda using Architect (arc.codes) framework.

A few words about Architect

To be honest, my first impression of this framework was quite skeptical. I had never heard of it before, and it seemed to me that there were already plenty of more popular solutions out there. Another one — especially with such low npm installation stats — just didn’t seem necessary.

But after working with it for a while, I was genuinely surprised. Honestly, it’s one of the most convenient tools I’ve come across in my 11 years of development.

That said, a bit of skepticism still remains. I did encounter a few bugs that were clearly caused by the simple lack of maintenance — and that’s a red flag for me. Because of this, I wouldn’t recommend using it for huge projects. I’ll share one of these issue at the end, along with a simple workaround.

So..

Architect calls itself a framework (which I completely disagree with — it feels more like a library to me). It lets you define your AWS infrastructure as code while providing an excellent developer experience. It supports NodeJS, Python, and Deno, but I’ve only used it with NodeJS so far.

Website, GitHub, NPM

Alright, let’s get to the fun part

I’ll show you how to build simple CRUD operations for a User entity in NodeJS, run the backend locally, and deploy it to AWS Lambda together with all the necessary infrastructure — including DynamoDB.

The beginning is pretty standard, so I won’t go into too much detail.
After installing Architect and initializing the project, we’ll install all dependencies needed for DynamoDB, AWS Lambda, and type definitions.

yarn init

yarn add -D @architect/architect
yarn add -D architect/plugin-typescript
yarn add -D @aws-lite/dynamodb-types
yarn add -D @types/node

npx arc init

yarn add @architect/functions
yarn add @aws-sdk/client-dynamodb
yarn add @aws-sdk/lib-dynamodb

Let’s add all the necessary commands for running and deploying right away.
I want to highlight the yarn dev command here — it runs the sandbox script, which starts the local environment (including all dependencies) and can even populate the database with test data. I’ll show how that works a bit later.

{
  "scripts": {
    "dev": "npx arc sandbox",
    "deploy:production": "npx arc deploy --production",
    "deploy:staging": "npx arc deploy --staging"
  },
}

To start, I want to create a contract between the Architect API and my small application’s code.
For that, I only need a single type — Response — which defines the format of how the main application code communicates responses back to the framework.

Response:

export type Response<T> = 
  | {
      code: 200,
      payload: T,
    }
  | {
      code: 500 | 404,
      payload: string,
    };

Since I prefer modular architecture and layering, I’ll create a folder modules/user with three subfolders to separate business logic from infrastructure.

domain — contains services and entities

User entity:

export type User = {
  id: string;
  name: string;
  email: string;

  createdAt: string;
  updatedAt: string;
};

UserService:

import type { User } from '../entity';

export interface IUserRepository {
  findById: (id: string) => Promise<User | undefined>;
  deleteById: (id: string) => Promise<void>;
  create: (userData: Omit<User, 'id' | 'createdAt' | 'updatedAt'>) => Promise<User>;
  update: (userData: Omit<User, 'createdAt' | 'updatedAt'>) => Promise<void>;
};

export class UserService {
  private repository: IUserRepository;

  constructor(repository: IUserRepository) {
    this.repository = repository;
  }

  public async getUserById(id: string): Promise<User | undefined> {
    return this.repository.findById(id);
  }

  public async createUser(userData: Omit<User, 'id' | 'createdAt' | 'updatedAt'>): Promise<User> {
    return this.repository.create(userData);
  }

  public async updateUser(userData: Omit<User, 'createdAt' | 'updatedAt'>): Promise<void> {
    return this.repository.update(userData);
  }

  public async deleteUserById(id: string): Promise<void> {
    return this.repository.deleteById(id);
  }
};

infrastructure — contains repositories for DynamoDB access

User Repository: (here is connection to AWS DynamoDB, and a special “kung-fu” technique with a private constructor and an asynchronous factory method for creating the class, since the database connection is established asynchronously as well)

import crypto from 'node:crypto';
import arc from '@architect/functions';
import type { ArcDB } from '@architect/functions/types/tables';

import { User } from '../../domain/entity';
import { IUserRepository } from '../../domain/service';

type UserTable = {
  users: User;
};

export class UserDynamoDBRepository implements IUserRepository {
  private db: ArcDB<UserTable>;

  private constructor(db: ArcDB<UserTable>) {
    this.db = db;
  }

  public static async create() {
    const db = await arc.tables<UserTable>();

    return new UserDynamoDBRepository(db);
  }

  public async findById(id: string): Promise<User | undefined> {
    return this.db.users.get({ id });
  }

  public async deleteById(id: string): Promise<void> {
    await this.db.users.delete({ id });
  }

  public async create(userData: Omit<User, 'id' | 'createdAt' | 'updatedAt'>): Promise<User> {
    const id = crypto.randomUUID();

    const createdAt = new Date().toISOString();

    return this.db.users.put({
      id,
      ...userData,
      createdAt,
      updatedAt: createdAt,
    });
  }

  public async update(userData: Omit<User, 'createdAt' | 'updatedAt'>): Promise<void> {
    const { id, ...data } = userData;

    const updatedAt = new Date().toISOString();

    const payload = { ...data, updatedAt };

    const updateExpression = Object.keys(payload).map((key) => `#${key} = :${key}`).join(', ');

    const expressionAttributeNames = Object.fromEntries(
      Object.keys(payload).map((key) => [`#${key}`, key])
    );

    const expressionAttributeValues = Object.fromEntries(
      Object.entries(payload).map(([key, value]) => [`:${key}`, value])
    );

    await this.db.users.update({
      Key: { id: userData.id },
      UpdateExpression: `set ${updateExpression}`,
      ExpressionAttributeNames: expressionAttributeNames,
      ExpressionAttributeValues: expressionAttributeValues,
    });
  }
};

presentation — contains controllers, which will later be invoked by AWS Lambda

User Controller:

import { Response } from '../../../common/presentation';

import { User } from '../../domain/entity';
import { UserService } from '../../domain/service';
import { UserDynamoDBRepository } from '../../infrastructure/repository/UserDynamoDBRepository';

export class UserController {
  private service: UserService;

  private constructor(service: UserService) {
    this.service = service;
  }

  public static async create() {
    const repository = await UserDynamoDBRepository.create();

    const service = new UserService(repository);

    return new UserController(service);
  }

  public async getUserById(id: string): Promise<Response<User>> {
    try {
      const user = await this.service.getUserById(id);

      if (!user) {
        return {
          code: 404,
          payload: 'User not found',
        };
      }

      return {
        code: 200,
        payload: user,
      };
    } catch (error) {
      return {
        code: 500,
        payload: 'Internal server error',
      };
    }
  }

  public async deleteUserById(id: string): Promise<Response<void>> {
    try {
      await this.service.deleteUserById(id);

      return {
        code: 200,
        payload: undefined,
      };
    } catch (error) {
      return {
        code: 500,
        payload: 'Internal server error',
      };
    }
  }

  public async createUser(userData: Omit<User, 'id' | 'createdAt' | 'updatedAt'>): Promise<Response<User>> {
    try {
      const user = await this.service.createUser(userData);

      return {
        code: 200,
        payload: user,
      };
    } catch (error) {
      return {
        code: 500,
        payload: 'Internal server error',
      };
    }
  }

  public async updateUser(userData: Omit<User, 'createdAt' | 'updatedAt'>): Promise<Response<void>> {
    try {
      await this.service.updateUser(userData);

      return {
        code: 200,
        payload: undefined,
      };
    } catch (error) {
      return {
        code: 500,
        payload: 'Internal server error',
      };
    }
  }
};

That’s it! We’ve finished the application code — now let’s integrate it into our framework.
Let’s create separate directories outside the modules for each CRUD operation: src/http/get-user, src/http/put-user, src/http/post-user, and src/http/delete-user.
The exact location of these functions doesn’t really matter — I just chose these folder names for my own organization.

src/http/get-user

import arc from '@architect/functions';
import type { HttpRequest, HttpResponse } from '@architect/functions/types/http';

import { UserController } from '../../modules/user/presentation/controller/UserController';

export const handler = arc.http.async(async (request: HttpRequest): Promise<HttpResponse> => {
  const { userId } = request.pathParameters;

  const controller = await UserController.create();

  const response = await controller.getUserById(userId);

  return {
    statusCode: response.code,
    json: {
      payload: response.payload,
    },
  };
});

src/http/post-user

import arc from '@architect/functions';
import type { HttpRequest, HttpResponse } from '@architect/functions/types/http';

import { UserController } from '../../modules/user/presentation/controller/UserController';

export const handler = arc.http.async(async (request: HttpRequest): Promise<HttpResponse> => {
  const { name, email } = request.body;

  const controller = await UserController.create();

  const response = await controller.createUser({ name, email });

  return {
    statusCode: response.code,
    json: {
      payload: response.payload,
    },
  };
});

I won’t include the code for the other functions, as they follow the same pattern.

So, here’s the most interesting part — the main configuration file is called app.arc. It can come in different formats, like YAML, if that’s more convenient for you, but I kept the default format.

In this file, we define the entire infrastructure configuration, including all routes (later, a separate AWS Lambda will be created for each), tables, AWS region, and so on. You can find more information here, but this basic config pretty simple.

Additionally, we specify plugins and my little esbuild.js hack, which I’ll explain a bit later.

@app
# App name
devto

@aws
# App region
region us-west-2
# This param is necessary for architect/plugin-typescript plugin
runtime typescript

@plugins
# Typescript support
architect/plugin-typescript

@typescript
# Additional build configuration
esbuild-config esbuild.js

# Routes
@http
/api/user/:userId
  method get
  src src/http/get-user
/api/user/:userId
  method put
  src src/http/put-user
/api/user/:userId
  method delete
  src src/http/delete-user
/api/user
  method post
  src src/http/post-user

# DynamoDB tables
@tables
users
  id *String

And that’s it! With such a simple configuration, we get a fully functioning infrastructure on AWS Lambda.

Let's try to run it locally

But first, let’s pre-populate our local database with some test users. To do this, we can simply create a JSON file named sandbox-seed.json in the project root, containing data for all the tables we need.

{
  "users": [
    {
      "id": "7e90d8f0-2c39-4d0c-8e5e-403a03ccda93",
      "email": "text@example.com",
      "name": "John Jonson",
      "createdAt": "2023-01-01T00:00:00.000Z",
      "updatedAt": "2023-01-01T00:00:00.000Z"
    }
  ]
}

...and...

yarn dev

✓ Sandbox @tables created in local database
✓ Sandbox @http (HTTP API mode / Lambda proxy v2.0 format / live reload) routes
    get /api/user/:userId ................. src/http/get-user
    get /* ................................ public/
   post /api/user ......................... src/http/post-user
    put /api/user/:userId ................. src/http/put-user
 delete /api/user/:userId ................. src/http/delete-user

    http://localhost:3333

Here it is — our test user from the seed file:

GET http://localhost:3333/api/user/7e90d8f0-2c39-4d0c-8e5e-403a03ccda93

HTTP/1.1 200 OK
{
  "payload": {
    "id": "7e90d8f0-2c39-4d0c-8e5e-403a03ccda93",
    "email": "text@example.com",
    "name": "John Jonson",
    "createdAt": "2023-01-01T00:00:00.000Z",
    "updatedAt": "2023-01-01T00:00:00.000Z"
  }
}

Now we can easily create, update, and delete users locally. It’s quite simple and convenient. By default, this mode comes with livereload, but that and many other settings are easy to configure.

But even more interesting is how easily we can deploy this to AWS from scratch.

Deploy

yarn deploy:production

         App ⌁ devto
      Region ⌁ us-west-2
     Profile ⌁ default
     Version ⌁ Architect 11.3.0

Compiled project in 0.157s
⚬ Deploy Creating new private deployment bucket: devto-cfn-deployments-b0eb2
⚬ Deploy Initializing deployment
✓ Deploy Generated CloudFormation deployment
✓ Deploy Deployed & built infrastructure
✓ Success! Deployed app in 78.558 seconds

    https://rncj6atj15.execute-api.us-west-2.amazonaws.com

✨  Done in 80.92s.

..easy... The entire infrastructure was created from scratch in AWS, and it took just over a minute.

A few requests to check..

POST https://rncj6atj15.execute-api.us-west-2.amazonaws.com/api/user

{
  "email": "test@example.com",
  "name": "John Jonson"
}

HTTP/1.1 200 OK

{
  "payload": {
    "id": "83024338-db08-4756-a43d-04a36cb031d8",
    "email": "test@example.com",
    "name": "John Jonson",
    "createdAt": "2023-01-01T00:00:00.000Z",
    "updatedAt": "2023-01-01T00:00:00.000Z"
  }
}

GET https://rncj6atj15.execute-api.us-west-2.amazonaws.com/api/user/83024338-db08-4756-a43d-04a36cb031d8

HTTP/1.1 200 OK

{
  "payload": {
    "id": "83024338-db08-4756-a43d-04a36cb031d8",
    "email": "test@example.com",
    "name": "John Jonson",
    "createdAt": "2023-01-01T00:00:00.000Z",
    "updatedAt": "2023-01-01T00:00:00.000Z"
  }
}

PUT https://rncj6atj15.execute-api.us-west-2.amazonaws.com/api/user/83024338-db08-4756-a43d-04a36cb031d8

{
  "email": "john@example.com",
  "name": "John Jonson"
}

HTTP/1.1 200 OK

{
  "payload": {
    "id": "83024338-db08-4756-a43d-04a36cb031d8",
    "email": "john@example.com",
    "name": "John Jonson",
    "createdAt": "2023-01-01T00:00:00.000Z",
    "updatedAt": "2023-01-01T0:00:00.000Z"
  }
}

DELETE https://rncj6atj15.execute-api.us-west-2.amazonaws.com/api/user/83024338-db08-4756-a43d-04a36cb031d8

HTTP/1.1 200 OK

GET https://rncj6atj15.execute-api.us-west-2.amazonaws.com/api/user/83024338-db08-4756-a43d-04a36cb031d8

HTTP/1.1 404 OK

{
  "payload": "User not found"
}

The end.. happy end..

Conclusion

This is a very basic example showing the simplest capabilities of Architect. However, I’ve also used it with queues, WebSockets, and scheduled tasks — all just as easy as what’s described in this article. And, in my opinion, the most important point is that this framework fits nicely with DDD (Domain-Driven Design) patterns. Yes, in my example DDD is implemented very lightly, but it clearly shows that Architect doesn’t force you to deeply integrate its API into your application code — you can easily separate or replace it in the future. All in all, it’s a really cool tool! :)

P.S. And here’s the hack I mentioned earlier. In the version of Architect I used (specifically the @architect/plugin-typescript plugin), I found a bug related to support for an older version of the AWS library for DynamoDB.

In Architect’s code, there’s a check for the current NodeОЫ version. If it’s below 18, it tries to use the old AWS library, dynamically importing it with require(...). However, esbuild, which runs inside the @architect/plugin-typescript plugin, tries to bundle this import regardless of whether the condition for loading it is met.

To fix this, my custom ESLint configuration simply disables bundling for that problematic package.

eslint.js

module.exports = {
  external: ['aws-sdk/clients/dynamodb'],
}

Frontend architecture. Introduction

Dmitrii Nefedov — Wed, 22 Oct 2025 21:02:10 +0000

Hi everyone!

My name is Dmitrii, and I’ve been working as a frontend developer for the past 11 years. Over my career, I’ve had the chance to build a wide variety of web applications — from small startups to core, high-traffic products for some of the largest tech companies in the country.

This is actually my first article ever and honestly, not the easiest topic to start with. But let’s see how it goes.

I want to start a series of articles on a topic that has been on my mind a lot in recent years — frontend application architecture. Actually, this isn’t just about frontend — many of the ideas apply to software in general, regardless of language or platform. But since my experience is mainly in frontend, that’s the perspective I’ll focus on. Much of this will also apply to backend applications built with Node.js.

Before we begin, if you already have your favorite approach to frontend architecture, that’s great. I’m not claiming to hold the ultimate truth here. What I’ll share is simply a reflection on my personal experience and what I’ve learned over the years — mostly as a full-stack developer (NodeJS + React/Vue) working on projects with constantly changing requirements. You won’t find any revolutionary insights here, just my way of structuring and reasoning about applications. Hopefully, it will give someone food for thought, spark a bit of constructive criticism (which I always welcome), or simply help organize thoughts you might already have.

Motivation

After experimenting with different architectural patterns (Layered Design, Feature-Sliced Design, Atomic Design, Clean Architecture), I realized that none of them fully satisfied me. Each worked well at certain stages of a project’s life cycle — but transitioning from one pattern to another as the system grew was extremely painful, both technically and for the business.

And yet, after a few years, almost every project I worked on naturally evolved into some form of Clean Architecture — or sometimes a mix of Clean Architecture, DDD, and Hexagonal Architecture — often carrying along the technical baggage of the patterns we started with. That’s why I began thinking about how this transition could be made smoother and less painful.

What are Clean Architecture, DDD, and Hexagonal Architecture — and why do we always end up there?

I don’t plan to dive deep into these patterns in this article — many books and articles already do that far better than I could here. But I also can’t continue without providing some context, so I’ll just highlight the essence — the part I believe matters most right now.

Clean Architecture, DDD, and Hexagonal Architecture are slightly different approaches to implementing one simple idea: separating business logic from everything else. The goal is to make the system easier to maintain and evolve.

This idea might sound simple — but in practice, it’s the very thing that determines whether a project will continue growing for years or eventually turn into a hard-to-evolve system, where each new feature takes longer to implement and confidence in its stability keeps shrinking.

What’s next

In the next article, I’ll go deeper into this and show how I prefer to structure applications at the highest level of abstraction — starting with how I separate them into modules and layers.