Metarhia vs Express vs NestJS

Чем стек автора принципиально отличается от mainstream Node.js-фреймворков.

Express

  • Парадигма: низкоуровневый HTTP-роутер + middleware-chain.
  • app.get('/api/users', handler) — ручной роутинг.
  • Нет ничего: ни валидации, ни DI, ни логирования, ни изоляции.
  • автор: «Middleware антипаттерн для Node.js в 2026» — middleware-chain плохо ложится на сложные системы.

NestJS

  • Парадигма: Controllers + Services + DI (как Spring/Angular).
  • Сильная типизация, декораторы, модули.
  • REST/GraphQL/WebSocket — раздельные слои, каждый со своим API.
  • Изоляции приложений нет — один процесс, всё в одном неймспейсе.

Metarhia (Impress + Metacom)

  • Парадигма: Application server + RPC protocol.
  • Нет роутинга — структура папок API/v1/users/get.js автоматически экспортится как RPC-метод.
  • Один транспорт — Metacom поверх WebSocket/HTTP/WebRTC. UI вызывает api.users.get(id), не зная, как идёт пакет.
  • Sandbox на приложение — V8 vm изолирует код, утечка лечится пересозданием sandbox.
  • Многопоточность из конфига — балансер + сетевые треды + worker pool, без ручного worker_threads.
  • Контракты в metaschema — типы и валидация декларативно, общие для БД/API/доменной модели.

Ключевые расхождения

Что Express/Nest Metarhia
Routing руками или декораторы автозагрузка из ФС
API endpoint URL + HTTP-метод имя интерфейса.имя метода
Транспорт привязан к HTTP прозрачно меняется
Клиентский SDK пишется отдельно генерируется из introspection
Изоляция нет sandbox
Threads вручную конфигурация
Hot reload rebuild подгрузка в sandbox

Когда что выбирать

  • Express/Fastify — простой HTTP/REST, маленькие сервисы, легаси.
  • NestJS — большие enterprise-команды на TypeScript, нужны стандартные паттерны DI, готовая экосистема.
  • Metarhia — высокие нагрузки, нужен RPC, готовы вложиться в обучение команды и нестандартный подход.

🎓 Источники

См. также