Sails.js в 2026: жив ли фреймворк и чем его заменить

Содержание

Эта статья была написана в 2016 году как введение в Sails.js — тогда это был живой выбор для тех, кому нужен «Rails для Node». Сегодня она честнее работает как ответ на другой вопрос: что стало с Sails и что брать вместо него.

Что такое Sails.js

Sails — фреймворк полного цикла, построенный поверх Express. Его идея: дать всё сразу, чтобы не собирать приложение из десятка пакетов.

В комплекте шло:

  • MVC-структура — контроллеры, модели, представления по соглашению;
  • Waterline — своя ORM, единый API к MySQL, PostgreSQL и MongoDB;
  • Blueprints — автоматические REST-маршруты для каждой модели, без единой строки кода;
  • WebSocket из коробки — тот же роутинг работал и по сокетам;
  • Генераторыsails generate api user создавал модель и контроллер.

Идея была сильная, и в 2016-м она била Express: там приходилось руками собирать роутер, парсер тела, ORM и валидацию.

Почему его перестали выбирать

Здесь важно не сказать неправды: Sails не сломался и не стал плохим. Изменилось то, чего экосистема хочет от фреймворка.

Две философии: почему победила вторая

Монолит «всё из коробки»

Sails, и отчасти его наследники

  • Быстрый старт: всё уже есть
  • Единые соглашения на весь проект
  • Своя ORM, свой роутинг, свои генераторы
  • Цена: выход за модель стоит дорого
  • Нестандартный запрос — боретесь с ORM
  • Обновление фреймворка тянет всё сразу

Небольшие заменяемые слои

Путь, которым пошла экосистема Node

  • HTTP-слой: Express или Fastify
  • ORM: Prisma, Drizzle — отдельно
  • Валидация: Zod — отдельно
  • Каждый слой меняется независимо
  • Не нравится ORM — меняете только ORM
  • Цена: собирать надо самому

Главная проблема любого монолитного фреймворка одинакова: он прекрасен, пока вы внутри его модели, и дорог ровно в тот момент, когда из неё выходите. Нужен запрос, который Waterline не выражает, — и вы пишете сырой SQL в обход ORM, теряя весь смысл абстракции.

Второй фактор — скорость самой платформы. Node за эти годы вобрал в себя половину того, ради чего брали фреймворк: fetch, WebSocket, тест-раннер теперь встроены. Ценность «всё в одном пакете» упала.

Чем заменить: зависит от того, что было нужно

Что вам было нужно от Sails Что брать в 2026
Структура и соглашения, DI, модули NestJS — идейный наследник, но живой
Просто HTTP-слой и роутинг Express — стандарт де-факто
То же, но быстрее и со схемами Fastify — валидация и сериализация из коробки
ORM к базе Prisma или Drizzle — отдельным слоем
Blueprints, авто-REST Генераторы NestJS либо готовый бэкенд-as-a-service
WebSocket Встроенный клиент + ws на сервере, или Socket.io

Практическое правило: если тянет к «всё из коробки» — это NestJS. Если нужен минимум и контроль — встроенный http или Express.

И честно: для небольшого API встроенного модуля http часто достаточно. Мы разбирали — маршрутизация и разбор JSON пишутся руками за десяток строк, и это на одну зависимость меньше.

Waterline: почему одна ORM к SQL и MongoDB — протекающая абстракция

Самая амбициозная часть Sails заслуживает отдельного разбора, потому что урок из неё общий.

Waterline обещал единый API к MySQL, PostgreSQL, MongoDB и Redis: пишете код один раз, а базу меняете строкой в конфиге. Звучит прекрасно — и упирается в то, что эти базы принципиально разные.

Что при этом происходит:

  • Общий знаменатель усыхает. Чтобы одинаково работать и с SQL, и с MongoDB, API должен уметь только то, что умеют обе. Ни оконных функций, ни CTE, ни агрегаций MongoDB — всё это остаётся за бортом.
  • Различия всё равно протекают. Транзакции есть в PostgreSQL и по-другому в MongoDB. JOIN в SQL — обычная операция, а в MongoDB $lookup дороже и означает, что модель выбрана неверно. Абстракция не может это спрятать — она может только притвориться.
  • Отладка удваивается. Сгенерированный запрос неоптимален — и вы разбираетесь уже в двух местах: в своём коде и в том, как ORM его перевела.

В итоге на любом нетривиальном запросе разработчик писал сырой SQL в обход Waterline — то есть терял ровно то, ради чего абстракцию и брал.

Именно поэтому современные инструменты сузили обещание. Prisma и Drizzle работают с SQL-базами и не делают вид, что MongoDB — это тоже таблица. Меньше обещаний — меньше протечек.

Урок шире одного фреймворка: абстракция, которая прячет принципиальные различия, а не случайные, обязательно протечёт. Вопрос только в том, на каком по счёту запросе.

Переписывать ли работающее приложение

Нет — если оно работает и вас устраивает. Переписывание с нуля — это риск, сроки и деньги в обмен на «стало современнее». Пользователю всё равно, на каком фреймворке ваш бэкенд.

Осмысленные поводы для миграции ровно два:

  1. Упёрлись в ограничение. Waterline не выражает нужные запросы, фреймворк мешает, а не помогает.
  2. Не можете нанять людей. Это реальная проблема умирающих технологий: специалистов не найти, а команда не хочет учить то, что не пригодится дальше.

Если ни одно не про вас — оставьте как есть и вкладывайтесь в продукт.

Что было на этой странице в 2016 году

Первая версия вышла 21 марта 2016 года и учила ставить Sails и создавать первый проект:

npm install sails -g
sails new myproject
sails lift

Три команды до работающего приложения с REST-API — в 2016-м это производило сильное впечатление, и статья честно передавала этот энтузиазм.

Что с тех пор изменилось: ничего в самом Sails. Команды всё те же, они и сейчас отработают. Изменилось окружение — вокруг выросли NestJS, Fastify, Prisma, а сама платформа Node вобрала половину того, ради чего брали фреймворк.

Это, пожалуй, главный урок этой страницы, и он полезнее любого туториала по Sails: технологии в вебе редко умирают от плохого качества. Их обычно просто перестают выбирать. Та же история — с Memcached: он не стал хуже, просто Redis занял нишу целиком.

Поэтому мы не стали делать вид, что 2016 год продолжается, и переписали урок установки в разбор «что с этим делать сегодня». Если вы пришли сюда по ссылке из старого проекта — вам, скорее всего, нужен был именно этот ответ.


Смежные темы: HTTP-сервер без фреймворков — сколько на самом деле нужно кода; Memcached — та же история про смену выбора; что такое Node.js. Полный список — в справочнике по Node.js.

Частые вопросы

Sails.js умер?
Проект существует, но экосистема ушла в другую сторону: новые проекты на нём почти не начинают. Если у вас работающее приложение на Sails — это не повод срочно переписывать, но для нового кода выбор другой.
Чем заменить Sails.js?
Зависит от того, что вам от него было нужно. Ради структуры «всё из коробки» — NestJS. Ради простого HTTP-слоя — Express или Fastify. Ради ORM — Prisma или Drizzle отдельным слоем.
Почему фреймворки «всё из коробки» вышли из моды в Node?
Они выигрывают, пока вы внутри их модели, и дорого стоят на выходе за неё. Экосистема Node пошла путём небольших слоёв, которые можно заменить поштучно.
Стоит ли переписывать работающее приложение на Sails?
Нет, если оно работает и вас устраивает. Переписывание — это риск и деньги. Осмысленный повод — когда упёрлись в ограничение фреймворка или не можете нанять людей.
Express ещё актуален?
Да, это по-прежнему самый распространённый выбор и стандарт де-факто. Fastify берут, когда важна производительность и встроенная валидация схем.