Стек технологий веб-проекта: из чего состоит и как его выбрать

Из чего состоит набор технологий

Стек — это всё, на чём работает продукт: языки, фреймворки, базы данных, сервисы и инфраструктура. Обычно его делят на клиентскую часть, которую видит пользователь, и серверную, где живут данные и бизнес-логика.

Каждый слой выбирают отдельно, но они должны дружить между собой. Хороший фреймворк с базой, под которую нет нормальных драйверов, создаст проблем больше, чем решит.

Сюда же относятся внешние сервисы, без которых магазин не работает: платёжный шлюз, службы доставки, почтовые рассылки, учётная система. Формально это не часть кода, но от них зависит выбор библиотек и архитектуры. Поэтому список интеграций стоит составить раньше, чем выбирать фреймворк.

Слои стека веб-проекта

• Фронтенд: HTML, CSS, JavaScript или TypeScript и фреймворки — React, Vue, Next.js, Nuxt.
• Бэкенд: PHP с Laravel или Symfony, Python с Django, Node.js, Go, Java.
• База данных: PostgreSQL, MySQL, MongoDB.
• Кеш и очереди: Redis, RabbitMQ.
• Поиск по каталогу: Elasticsearch или OpenSearch.
• Инфраструктура: Docker, Kubernetes, Nginx, системы CI/CD для автоматической сборки и выкладки.

Какие сочетания встречаются чаще всего

У популярных наборов есть устоявшиеся названия. Они полезны как ориентир, но реальный проект почти всегда собирают под свои задачи.

Наш стек: Laravel, Next.js и PostgreSQL

Главный аргумент — люди. Этот стек знают десятки тысяч разработчиков в стране, на hh.ru специалистов с большим запасом. Значит, клиент не попадает в зависимость от одной команды.

Laravel появился в 2011 году и стал одним из самых популярных PHP-фреймворков. Next.js — фреймворк на React, который умеет отдавать страницы с сервера, и для каталога с SEO это важно. PostgreSQL держит сложные выборки и транзакции, Redis отвечает за кеш, сессии и очереди, Docker делает окружение разработчика таким же, как на сервере.

Как выбрать технологии под проект

Я начинаю не с технологий, а с требований бизнеса. Мода на фреймворк проходит за пару лет, а проект живёт пять и больше.

• Рынок найма: сколько специалистов в вашем городе и на удалёнке, легко ли заменить человека.
• Зрелость: сколько лет технологии, кто её поддерживает, как часто выходят версии с ломающими изменениями.
• Лицензии: можно ли использовать бесплатно в коммерческом проекте и что будет, если вендор поменяет условия.
• Нагрузка: выдержит ли система пик, а не средний день.
• Интеграции: есть ли готовые библиотеки для 1С, платёжных шлюзов, служб доставки.
• Скорость запуска: сколько времени займёт первая рабочая версия.

Нагрузка, интеграции и безопасность

Для магазина «сайт за 10 минут» ничего не стоит, если он падает на распродаже. Он должен выдерживать пиковый трафик, обмениваться данными с 1С и проходить проверку безопасности, когда подключаешь банк. Платформа даёт ускорение запуска только вместе со стабильностью и возможностями развития. Time to market здесь король, но не ценой падения в чёрную пятницу.

Лицензии и привязка к вендору

Открытые технологии снижают риск, но не убирают его совсем. В марте 2024 года Redis сменил открытую лицензию BSD на RSALv2 и SSPL, и через неделю появился форк Valkey под крылом Linux Foundation. В 2025 году Redis 8 добавил к ним открытую AGPLv3, но часть облачных провайдеров уже перешла на Valkey. Для пользователя ничего не сломалось, но такие истории стоит учитывать. Закрытая платформа рискованнее: тарифы, ограничения и судьбу продукта решает одна компания.

Набор технологий и ИИ-агенты

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

Второе изменение — генерация контента. Кнопка «сгенерировать описание товара» становится встроенной частью админки, как и генерация лендингов, фото и текстов под SEO. Если стек не даёт удобно подключать модели, эту часть придётся долго прикручивать сбоку.

Третье — документация рядом с кодом. Агенту нужен не только код, но и объяснение, почему он устроен именно так. Чем лучше фреймворк описан в открытых источниках и чем аккуратнее проект оформлен внутри, тем меньше времени уходит на исправление того, что агент понял неправильно.

Частые ошибки при выборе

• Брать технологию, потому что она модная в этом году.
• Выбирать под одного сильного разработчика, который знает редкий язык.
• Начинать с микросервисов там, где хватило бы одного приложения.
• Смешивать в одном проекте три фреймворка, потому что каждый разработчик принёс свой любимый.
• Не проверять интеграции до старта и узнать о проблеме с 1С за месяц до запуска.
• Считать только стоимость разработки и забывать про поддержку на годы вперёд.

Как проверить выбор технологий до старта

Самую дорогую ошибку проще поймать на бумаге, чем в коде. Перед стартом я бы прошёл короткий список проверок.

Первое — прототип самой рискованной интеграции. Если магазин живёт на обмене с 1С, сначала нужно поднять этот обмен на тестовых данных, а уже потом рисовать каталог. Второе — нагрузочный тест на пиковый сценарий: открытие распродажи, рассылка по всей базе, выгрузка прайса. Третье — разговор с двумя-тремя разработчиками с рынка: готовы ли они работать на этом наборе и сколько это будет стоить.

И последнее — план выхода. Что будет, если технология перестанет развиваться или поменяет условия? Если ответа нет, лучше узнать это до запуска, а не через три года, когда переезд обойдётся в стоимость нового проекта.