Разработка веб-приложения: этапы и технологии
Веб-приложение — это не сайт с красивыми страницами, а программа, которая работает в браузере: личный кабинет, CRM, дашборд, маркетплейс, SaaS. У него есть фронтенд, бэкенд, API между ними и база данных — и сложность спрятана внутри, а не в вёрстке страниц.
Code Pilots с 2014 года делает заказные веб-приложения — порталы, CRM и ERP, кабинеты и SaaS с реальной нагрузкой, на стеке Vue, Symfony и PostgreSQL. Ниже — из чего приложение состоит, как выбрать стек, чем его этапы отличаются от сайта и где его легально разместить в России.
Веб-приложение и сайт: почему это разные задачи
Грань проходит не по «сложности», а по сути. Сайт в первую очередь показывает контент: человек читает, смотрит, оставляет заявку. Веб-приложение — это инструмент, в котором человек что-то делает: ведёт сделки, заполняет таблицы, управляет заказами, работает с данными под своей учётной записью. Сайт-визитку можно собрать на конструкторе; веб-приложение — это продукт с логикой, ролями, состояниями и нагрузкой, который на шаблоне не живёт.
Отсюда и разница в разработке: у приложения появляется то, чего у статического сайта нет, — модель данных, авторизация и роли, обновление информации в реальном времени, серьёзное тестирование и инфраструктура под нагрузку. Подробное сравнение «сайт против веб-приложения» и отдельно этапы создания сайта — это смежные темы; здесь исходим из того, что вам нужно именно приложение, и смотрим, как оно устроено внутри.
Из чего состоит веб-приложение: архитектура без мистики
Любое веб-приложение — это четыре слоя, которые общаются между собой. Понимать их полезно даже не-технарю: так проще говорить с подрядчиком и видеть, за что вы платите.
| Слой | За что отвечает | Простыми словами |
|---|---|---|
| Фронтенд | Интерфейс в браузере | Всё, что видит и нажимает пользователь |
| API | Связь фронтенда и бэкенда | «Официант» между залом и кухней: передаёт запросы и ответы |
| Бэкенд | Логика на сервере | «Кухня»: считает, проверяет права, обрабатывает данные |
| База данных | Хранение данных | Где лежат пользователи, заказы, документы |
Работает это так: пользователь нажимает кнопку во фронтенде, тот отправляет запрос через API на бэкенд, бэкенд достаёт или меняет данные в базе и возвращает ответ, фронтенд показывает результат. Чем чище спроектированы границы между слоями, тем проще приложение развивать и тем легче его передать другой команде.
Фронтенд: SPA или серверный рендеринг
Фронтенд — то, что видит пользователь, и у frontend-разработки веб-приложения есть развилка, которая влияет на скорость и поисковую видимость.
SPA (Single Page Application) — приложение целиком грузится в браузер и дальше работает без перезагрузки страниц, как настольная программа. Это даёт богатый интерактив и плавность — идеально для личных кабинетов и дашбордов, которые и так за авторизацией и в поиске не индексируются. Минус — хуже из коробки для SEO и чуть дольше первая загрузка.
Серверный рендеринг (SSR) и генерация статики (SSG) отдают браузеру уже готовую страницу с сервера — быстрее первый показ и лучше для поисковиков; это берут там, где приложению важна индексация (маркетплейсы, публичные каталоги).
Сами фреймворки фронтенда — это в основном React, Vue и Angular; мы работаем на Vue.js и считаем его оптимальным по балансу скорости разработки и поддержки для большинства бизнес-задач (подробное сравнение React и Vue — отдельная тема). Выбор между SPA и SSR делают по продукту: закрытый кабинет — почти всегда SPA, публичная витрина с упором на поиск — с серверным рендерингом.
Бэкенд, API и база данных
Бэкенд — это мозг приложения: бизнес-логика, проверка прав, интеграции с внешними системами (оплата, 1С, CRM), фоновые задачи. Он общается с фронтендом через API — обычно по REST или GraphQL; по сути это контракт, в котором заранее описано, какие запросы есть и что они возвращают. Хорошо описанный контракт API позволяет фронтенду и бэкенду разрабатываться параллельно и не зависеть друг от друга.
Данные хранятся в базе — для приложений с логикой и связями это чаще всего реляционная PostgreSQL. Устройство серверной части — большая отдельная тема; здесь важно видеть, что бэкенд, API и база — это три разные вещи, а не «сервер» одним словом.
Технологический стек в 2026: почему «лучшего» не существует
Вопрос «какой стек самый лучший» некорректен в той же мере, что и «какой инструмент лучший» — зависит от задачи. Стек подбирают под тип продукта, нагрузку, сроки и команду, а не по моде. Рынок в 2026 году выглядит примерно так:
| Слой | Популярные на рынке варианты | Что используем мы |
|---|---|---|
| Фронтенд | React, Vue, Angular (на JavaScript/TypeScript) | Vue.js |
| Бэкенд | PHP (Symfony/Laravel), Python (Django/FastAPI), Node.js, Java, Go | Symfony (PHP) |
| База данных | PostgreSQL, MySQL, MongoDB | PostgreSQL |
| Инфраструктура | Docker, Kubernetes, CI/CD | Docker |
Любой из распространённых стеков способен закрыть большинство задач — разница в нюансах: Python силён в данных и ML, Node удобен для реалтайма, PHP на Symfony — зрелый и предсказуемый для бизнес-приложений с интеграциями. Гораздо важнее стека две вещи: умеет ли команда хорошо готовить то, на чём пишет, и чисто ли спроектирована архитектура.
Красивый модный стек в руках, которые его не знают, проигрывает «скучному» стеку в руках senior-команды. Поэтому выбор стека под конкретный проект — это разговор про задачу и команду, а не про логотипы технологий.
Этапы разработки веб-приложения: чем они отличаются от сайта
Общая канва этапов — от аналитики и проектирования до тестирования и релиза — одинакова для любой разработки и разобрана в статье про жизненный цикл. У веб-приложения на каждом этапе появляется то, чего у сайта нет:
- Аналитика и модель данных. Сначала описывают не экраны, а сущности и связи: кто пользователи, какие у них роли, что с чем связано. Ошибка в модели данных — самая дорогая: переделывать её на работающем приложении больно.
- Проектирование API. Контракт между фронтендом и бэкендом фиксируют заранее, чтобы две части писались параллельно и стыковались без сюрпризов.
- Авторизация и роли. В приложении почти всегда есть учётные записи и разные права: админ видит одно, менеджер — другое. Это закладывают в архитектуру, а не прикручивают в конце.
- Реальное время и интеграции. Обновления без перезагрузки, уведомления, обмен с оплатой, 1С, внешними сервисами — то, что у статического сайта отсутствует.
- Тестирование под нагрузку и CI/CD. Приложение проверяют не только на «работает ли кнопка», но и на поведение под нагрузкой; релизы автоматизируют через CI/CD, чтобы обновления выкатывались предсказуемо.
- Масштабирование. Архитектуру с самого начала проектируют так, чтобы рост числа пользователей и данных не требовал переписывать всё заново.
Главное отличие от сайта: у веб-приложения сложность не на поверхности (в красоте страниц), а внутри — в данных, логике и нагрузке. Поэтому и доля работы аналитика и бэкенд-команды здесь несравнимо выше.
Где хостить веб-приложение в России в 2026: 152-ФЗ и облака
Техническую сторону обсуждают все, а вот про юридическую молчат — хотя в России она стала жёстким требованием. По закону 152-ФЗ персональные данные граждан России должны храниться на серверах, физически расположенных в стране, и с 1 июля 2025 года норму ужесточили: первичный сбор и хранение таких данных в зарубежных хранилищах прямо запрещены.
Для веб-приложения с регистрацией пользователей это значит, что разместить базу «где-нибудь на удобном зарубежном хостинге» нельзя — это нарушение с реальными штрафами.
Рабочее решение — российские облачные провайдеры, у которых дата-центры в РФ и есть сертификация под персональные данные:
| Провайдер | Особенность |
|---|---|
| Yandex Cloud | Сертификат ФСТЭК, подтверждён высокий уровень защищённости данных |
| VK Cloud | Облако с поддержкой требований по ПДн |
| Cloud.ru (SberCloud) | Крупный провайдер с защищёнными контурами |
| Selectel | Защищённое облако с соответствием 152-ФЗ |
| MTS Cloud | Облако с дата-центрами в РФ |
Важная деталь: физического размещения в России мало — закон требует ещё и технических мер защиты по требованиям ФСТЭК, плюс правильно оформленных отношений с провайдером (договор поручения на обработку данных). Это закладывают в проект на старте: перенести готовое приложение на соответствующую инфраструктуру задним числом дороже, чем сразу спроектировать под неё.
Для бизнеса вывод простой: вопрос «где хостить» в веб-приложении с пользователями — не технический пустяк под конец, а часть требований, которую учитывают вместе с архитектурой.
Частые ошибки при разработке веб-приложения
- Выбирать стек по хайпу. «Возьмём, потому что модно» вместо «возьмём под задачу и под команду» — частая причина медленной разработки и дорогой поддержки.
- Не зафиксировать контракт API. Без описанного заранее API фронтенд и бэкенд расходятся, и стыковка превращается в долгие переделки.
- Игнорировать нагрузку и масштабирование на старте. Архитектура, спроектированная под десять пользователей, рушится на тысяче — и переписывается с нуля в самый неподходящий момент.
- Забыть про 152-ФЗ. Удобный зарубежный хостинг для приложения с персональными данными россиян — это юридический риск, который всплывает уже после запуска.
- Делать без CI/CD и тестов. Ручные релизы и отсутствие автоматических проверок превращают каждое обновление в лотерею.
- Свалить логику во фронтенд. Когда проверки прав и важная логика живут в браузере, а не на бэкенде, это и дыра в безопасности, и источник ошибок.
С чего начать
Порядок такой: описать не экраны, а суть — пользователей, роли, сущности и связи (модель данных); спроектировать архитектуру и контракт API, чтобы части писались параллельно; выбрать стек под задачу и под команду, а не под моду; заложить с самого начала авторизацию, нагрузку и требования 152-ФЗ к хранению данных; настроить тестирование и CI/CD, чтобы релизы были предсказуемыми.
И помнить, что сложность веб-приложения — внутри, в данных и логике, а не в красоте страниц.
Самое дорогое в веб-приложении — ошибки в фундаменте: кривая модель данных, архитектура без запаса на рост, забытая юридическая сторона. Переделывать это на работающем продукте дороже, чем построить заново.
Code Pilots проектирует веб-приложения целиком — от модели данных и API до инфраструктуры под 152-ФЗ — на стеке Vue, Symfony, PostgreSQL и Docker, силами senior-команды без джунов. Расскажите о задаче — подскажем, какая архитектура и какой стек подходят именно вашему продукту.
Ориентиры по деньгам: веб-приложение мы делаем от 1 млн ₽, продукт под сложный бизнес-процесс — от 1,7 млн ₽, высоконагруженные проекты — от 5 млн ₽, отдельная интеграция — от 150 тыс. ₽. Разброс большой именно из-за нагрузки и интеграций, поэтому смету считаем по вашим требованиям — оценка бесплатная.
Часто задаваемые вопросы
Сайт в первую очередь показывает контент — его читают и смотрят. Веб-приложение — это инструмент, в котором работают: ведут сделки, заполняют данные, управляют заказами под своей учётной записью. У приложения есть модель данных, роли и права, обновления в реальном времени и нагрузка, которых у статического сайта нет; собрать его на конструкторе, как визитку, не получится.
«Лучшего» стека не существует — его подбирают под тип продукта, нагрузку, сроки и компетенции команды. На рынке распространены React/Vue/Angular на фронтенде и PHP/Python/Node на бэкенде; мы работаем на Vue, Symfony и PostgreSQL в Docker. Важнее самого стека то, насколько хорошо команда им владеет и чисто ли спроектирована архитектура.
Зависит от продукта. SPA (приложение целиком в браузере) даёт богатый интерактив и подходит для личных кабинетов и дашбордов, которые в поиске не индексируются. Серверный рендеринг (SSR) быстрее показывает первую страницу и лучше для SEO — его берут там, где приложению нужна поисковая видимость, например для маркетплейсов и публичных каталогов.
На российских серверах: по 152-ФЗ персональные данные граждан РФ должны храниться в дата-центрах внутри страны, а с 1 июля 2025 первичный сбор в зарубежных хранилищах прямо запрещён. Подходят российские облака с сертификацией под ПДн — Yandex Cloud, VK Cloud, Cloud.ru, Selectel, MTS Cloud. Одного размещения мало: нужны ещё технические меры защиты по требованиям ФСТЭК и договор с провайдером.
Да, и это разумный путь — начать с MVP и наращивать. Но архитектуру с самого начала проектируют с запасом на рост: «начать просто» не значит «начать без модели данных и продуманных границ». Приложение, собранное наспех под десять пользователей, на тысяче приходится переписывать; приложение, спроектированное под рост, просто масштабируют.
