Розробка бекенду на Express: від ідеї до модульної архітектури
Уявіть: сайт на монолітному PHP починає гальмувати при 10 000 запитів на хвилину. N+1 запити, відсутність кешування, час відповіді більше 2 секунд. Ви вирішуєте переписати бекенд на Node.js. Express — логічний кандидат: легкий, гнучкий, з величезним ком'юніті. Але як побудувати архітектуру, щоб витримати зростання і не потонути в спагеті-коді? Ми розберемо перевірений підхід: модульна архітектура, middleware-ланцюжки, кешування та graceful shutdown.
Які проблеми вирішує Express-бекенд?
Express залишається прагматичним вибором для бекенду: мінімум магії, передбачувана поведінка, величезна екосистема middleware. Не найшвидший фреймворк (Fastify швидше на 20–30% у бенчмарках), не найбагатший на функції (NestJS багатший), але поєднання простоти та гнучкості робить його робочим інструментом для більшості завдань. Головні проблеми, які ми вирішуємо:
- Спагеті-код — хаотична структура, коли роути, бізнес-логіка та доступ до даних змішані. Це призводить до того, що зміна одного модуля ламає інший.
- Вузькі місця продуктивності — N+1 запити, відсутність кешування, неоптимальні індекси в БД. Ми використовуємо Redis для кешування та Prisma для ефективних запитів. Наприклад, в одному проєкті TTFB знизився з 500 мс до 50 мс після впровадження кешування.
- Проблеми безпеки — невалідовані вхідні дані, вразливості JWT, відкриті CORS-політики. Валідація через Zod знижує кількість багів на 30–40%.
- Складність підтримки — відсутність єдиного стилю, тестів та документації. Кожен модуль покриваємо unit-тестами, для API — e2e-тести (Vitest, Supertest).
Як модульна архітектура вирішує проблеми масштабування?
В основі — модульна архітектура з розділенням на Router → Service → Repository. Це масштабується від лендінгу до enterprise-системи. Ось як виглядає структура типового проєкту:
src/
├── config/
│ ├── env.ts # typed env validation (zod)
│ └── database.ts
├── modules/
│ ├── users/
│ ├── products/
│ └── orders/
├── middleware/
│ ├── auth.ts
│ ├── errorHandler.ts
│ ├── requestLogger.ts
│ └── rateLimit.ts
├── lib/
│ ├── database.ts # Prisma client
│ ├── redis.ts
│ ├── mailer.ts
│ └── queue.ts
└── app.ts
Така архітектура дає чіткі межі відповідальності: роути парсять запит, сервіси містять бізнес-логіку, репозиторії працюють з даними. Порівняйте з плоскою структурою:
| Аспект | Плоска структура | Модульна архітектура |
|---|---|---|
| Масштабування | Важко | Легко (додаємо модулі) |
| Тестування | Хаотичне | Ізольоване (mock репозиторіїв) |
| Перевикористання | Низьке | Високе (сервіси незалежні) |
| Розуміння коду | Тільки автором | Командне |
Приклад модуля: Products
// modules/products/products.service.ts
import { ProductsRepository } from './products.repository';
import { redis } from '../../lib/redis';
export class ProductsService {
private repo = new ProductsRepository();
async list(query: ListProductsQuery) {
const cacheKey = `products:list:${JSON.stringify(query)}`;
const cached = await redis.get(cacheKey);
if (cached) return JSON.parse(cached);
const result = await this.repo.findMany(query);
await redis.set(cacheKey, JSON.stringify(result), 'EX', 300);
return result;
}
async getById(id: string) {
const cacheKey = `products:${id}`;
const cached = await redis.get(cacheKey);
if (cached) return JSON.parse(cached);
const product = await this.repo.findById(id);
if (product) await redis.set(cacheKey, JSON.stringify(product), 'EX', 3600);
return product;
}
async create(data: CreateProductDto, createdBy: string) {
const product = await this.repo.create({ ...data, createdBy });
const keys = await redis.keys('products:list:*');
if (keys.length > 0) await redis.del(keys);
return product;
}
}
Для складніших проєктів використовується BFF (Backend For Frontend) та Edge Functions для прискорення відповіді. Як рекомендовано в документації Express, middleware-ланцюжки дозволяють гнучко розширювати функціональність.
Чому валідація через Zod знижує кількість багів?
Валідація вхідних даних — критична точка. Ми використовуємо Zod: він забезпечує строгу типізацію на рівні TypeScript і автоматично генерує читабельні повідомлення про помилки. За статистикою наших проєктів, перехід на Zod знижує кількість багів, пов'язаних з некоректними даними, на 30–40%.
// src/config/env.ts
import { z } from 'zod';
const envSchema = z.object({
NODE_ENV: z.enum(['development', 'test', 'production']).default('development'),
PORT: z.coerce.number().default(3000),
DATABASE_URL: z.string().url(),
REDIS_URL: z.string().url(),
JWT_SECRET: z.string().min(32),
JWT_REFRESH_SECRET: z.string().min(32),
ALLOWED_ORIGINS: z.string().default('http://localhost:5173'),
});
export const env = envSchema.parse(process.env);
Падіння при старті з явним повідомленням про помилку краще, ніж незрозуміла поведінка в рантаймі при відсутності змінної оточення. До того ж Zod інтегрується зі Swagger для генерації схем.
Налаштування застосунку та middleware
Ключові точки конфігурації — безпека, логування та валідація. Використовуємо helmet, cors з білим списком доменів, pino-http для логів. Валідацію вхідних даних довіряємо zod — це дає строгу типізацію та читабельні помилки. Також налаштовуємо rate limiting (express-rate-limit) та захист від CSRF (csurf).
Як відбувається деплой та моніторинг?
Деплой налаштовуємо через Docker та CI/CD (GitHub Actions). Контейнеризація гарантує відтворюваність оточення. Моніторинг — Sentry для помилок, Grafana для метрик (кількість запитів, час відповіді, використання пам'яті). Типові показники: 99.9% аптайм, час відповіді <100 мс після прогріву кешу, пропускна здатність до 2000 RPS.
Процес роботи
- Аналітика — виявляємо вузькі місця, проєктуємо модулі, обираємо стек (Express, Prisma, Redis).
- Розробка — пишемо модулі, middleware, тести (Vitest). Кожен модуль покриваємо unit-тестами, для API — e2e-тести.
- Документація — генеруємо OpenAPI-специфікацію, яка автоматично оновлюється.
- Деплой — налаштовуємо CI/CD, Docker-контейнеризацію, моніторинг (Sentry, Grafana).
- Підтримка — гарантія 3 місяці, SLA — 4 години в робочий час.
Порівняння інструментів для Express бекенду
| Інструмент | Призначення | Перевага |
|---|---|---|
| Prisma | ORM | Типобезпека, міграції, автокомпліт |
| Redis | Кешування | Час відповіді < 1 мс, підтримка TTL |
| Zod | Валідація | Інтеграція з TypeScript, авто-помилки |
| Pino | Логування | Низьке споживання пам'яті, структуровані логи |
| Vitest | Тестування | Швидкий, сумісний з Vite |
Що входить в роботу
- REST API з модульною архітектурою (8–15 модулів)
- Аутентифікація та авторизація (JWT + refresh tokens)
- Кешування через Redis, інвалідація за ключами
- Graceful shutdown, обробка помилок, логування
- Документація OpenAPI, інструкція з запуску
- Доступ до репозиторію, CI/CD-пайплайн
- Навчання команди (2 години онлайн)
Строки та вартість
Строки: від 4 тижнів для MVP до 8 тижнів для повноцінного продукту. Вартість розраховується індивідуально — залежить від кількості модулів, інтеграцій та необхідної продуктивності. Оцінимо ваш проєкт за 1–2 дні. За рахунок оптимізації кешування та архітектури вдається суттєво економити на інфраструктурі.
Отримайте консультацію — напишіть нам, і ми запропонуємо архітектуру та строки під вашу задачу. Зв'яжіться з нами, щоб обговорити деталі. Наш досвід: понад 5 років на ринку, 50+ успішних проєктів на Node.js, сертифіковані інженери з Express та Prisma.