Разработка на Velo (Wix): где ломается типовой шаблон
Штатный конструктор закрывает витрину, каталог, формы заявок и оплату — на старте типовой шаблон выглядит достаточным. Пределы штатного функционала проявляются позже: когда к сайту прирастает логика бизнеса, а не контент — расчёты прямо в интерфейсе, роли пользователей, обмен с внешними сервисами.
Калькулятор со скидками, тарифами и зависимостью цены от комплектации в конструкторе собирается набором условий. Он держится до первой смены прайса: дальше цены дублируются в нескольких местах, и ошибка в одной из копий уезжает клиенту в счёт.
Роли упираются в то, что доступ разводится по страницам, а не по данным: партнёр, клиент и менеджер видят один и тот же кабинет с разными кнопками. Обмен со складом, учётной системой или платёжным провайдером держится на ручной выгрузке, пока объём заказов позволяет её не замечать.
Дальше растут коллекции, и первыми сдают узкие места интерфейса: фильтры по каталогу из тысяч позиций, выборки в кабинете, отчёты. Отклик падает, поддержка занимается не развитием, а тушением — доработка сайта на конструкторе превращается в переписывание.
Разбираем, как это закрывается: разработка на Velo (Wix) — это программирование поверх штатного слоя. Логика расчётов, права и обмен живут в коде, который версионируется и тестируется, а редактор остаётся для контента.
Что даёт кастомная разработка на Velo (Wix)
Кастомная логика на платформе меняет не внешний вид страницы, а поведение системы под нагрузкой. Часть ручных операций уходит в код: вместо выгрузки, правки и обратной загрузки таблицы сотрудник нажимает одну кнопку. Заодно исчезает класс отказов, связанный с рассинхроном между формой, таблицей и внешним сервисом.
Velo — среда разработки внутри Wix, где серверный код живёт рядом с интерфейсом и коллекциями данных. Отсюда доступ к событиям элементов, плановым задачам, входящим вызовам и внешним сервисам — тому, чем штатный конструктор не управляет.
Скорость работы интерфейса при росте базы
Штатная привязка элементов к коллекции тянет всю выборку: на сотнях записей это незаметно, на десятках тысяч список открывается с задержкой. Мы переносим фильтрацию и постраничный вывод на сервер, добавляем индексы по полям поиска и подгружаем связанные записи только по требованию.
Время выдачи результата перестаёт зависеть от объёма базы: рост в разы не превращается в секунды ожидания, а тяжёлые расчёты уходят в фоновые задачи.
Где кастомная логика нужна, а где хватает штатных средств
Штатных средств достаточно для витрины, каталога, формы заявки и блога. Кастомная логика нужна там, где появляются права на уровне отдельных записей, многошаговые согласования, расчёты по формулам, аудит изменений и двусторонняя синхронизация с внешними системами.
Обратная ошибка — переписывать в код то, что платформа делает сама: объём поддержки растёт, а выигрыша нет. Поэтому на этапе оценки мы размечаем задачи по этому признаку и прямо говорим, что закрывается настройкой.
Варианты реализации: модули, внешний сервис, гибрид
Выбор варианта определяется не объёмом кода, а профилем нагрузки и тем, где живут данные. Штатные средства платформы закрывают формы, каталоги, личные кабинеты и сценарии с умеренной логикой; как только появляются расчёты по расписанию, массовые выборки или обмен с внешними учётными системами, встаёт вопрос — держать всё внутри или вынести часть наружу.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Модули платформы | Логика укладывается в один запрос, данные небольшие, отчётность простая | Долгие вычисления упираются в лимит времени выполнения, массовые выборки идут постранично |
| Внешний сервис для расчётов | Пересчёты по расписанию, очереди задач, тяжёлая аналитика | Нужны синхронизация данных, отдельный контур доступа и контроль отказов связи |
| Гибридная схема хранения | Быстрые чтения в интерфейсе, тяжёлые данные — вне платформы | Сложнее отслеживать целостность: нужны идемпотентные обмены и повторная доставка |
Когда достаточно штатных средств
Модули платформы дают готовые коллекции данных, разграничение прав и код на стороне сервера. Этого хватает, если сценарий укладывается в ограничения по времени ответа и объёму выборки, а сторонние системы не требуют постоянного обмена. Ограничения варианта предсказуемы и проверяются на этапе проектирования — тогда внешние сервисы не нужны вовсе.
Когда оправдан внешний сервис
Внешний сервис для расчётов берут под регулярные пересчёты, отчёты и обработку очередей, где важнее устойчивость, чем мгновенный ответ. Гибридная схема оставляет витрину и быстрые чтения на платформе, а тяжёлые данные синхронизирует по событиям — при этом каждая операция обмена повторяема, поэтому сбой связи не приводит к расхождению данных.
Как проходит проект: этапы инженерной работы
Перед первой строкой кода фиксируем, как приложение будет расти: сколько появится коллекций, кто и что сможет читать, что произойдёт при откате. Такой порядок убирает переделки — интерфейс и логика строятся поверх согласованной структуры данных, а не наоборот.
Схема данных и права
- Разбор задачи и ограничений — какие сценарии закрывает приложение, что уже работает, какие ограничения платформы нельзя обойти.
- Аудит текущего решения — смотрим существующие страницы, коллекции, дубли полей и неочевидные связи, которые нельзя ломать при обновлении.
- Схема данных коллекций — описываем сущности, связи и индексы: где живёт заявка, где статус, где история изменений и кто её пишет.
- Настройка прав доступа — роли, правила чтения и записи, ограничение видимости полей, закрытие служебных коллекций от внешних запросов.
- Реализация логики — сценарии, интеграции с оплатой и уведомлениями, обработка ошибок и повторных отправок формы.
- Проверка на тестовой копии — прогоняем ключевые пути на копии с обезличенными данными до переноса на рабочий сайт.
- Перенос и приёмка — публикация, проверка на реальных данных, передача доступов и документации, обучение вашей команды.
Схему коллекций согласуем до разработки: перестроить структуру после запуска дороже, чем спроектировать её за день. Приёмку ведём по списку сценариев — видно, какие пути проверены на копии, а не только то, что «всё работает».
Что остаётся у вас: код, схемы, регламенты, доступы
Проект заканчивается не публикацией, а передачей. Заказчик получает полный комплект — от исходных модулей до прав администратора, — по которому приложение можно развивать и поддерживать без нас.
- Исходный код проекта: модули Velo с комментариями к неочевидным местам, полная история изменений в вашем репозитории, а не в нашем архиве.
- Описание структуры данных: назначение каждой коллекции, типы полей, связи между сущностями, обязательность и правила проверки значений.
- Политики доступа по ролям: матрица «роль — действие» на чтение и запись, настройки приватности данных, перечень служебных учётных записей.
- Регламент выкладки изменений: последовательность правок, проверок и публикации, а также порядок откатa на предыдущую рабочую версию.
- Инструкция для редакторов: как обновлять контент, добавлять страницы и блоки, что можно менять самостоятельно, а что требует инженера.
- Схемы интеграций: перечень внешних сервисов, форматы обмена, точки отказа и порядок действий при недоступности партнёрского сервиса.
- Доступы администратора: передача прав владельца площадки, домена, файлового хранилища и репозитория на ваши аккаунты.
Документацию собираем так, чтобы новый разработчик вошёл в проект за дни, а не за недели: описание данных и прав совпадает с фактической конфигурацией, а не живёт отдельно от неё. Передачу прав фиксируем актом — после него наши доступы отзываются, дальнейшая поддержка идёт по вашему запросу.
Кейс: личный кабинет с расчётами и ролями
Поставщик оборудования в аренду принимал заявки в таблицах: менеджер вручную выбирал тариф, считал срок и скидку, отправлял расчёт письмом. Клиент не видел статус заявки и звонил уточнять, а расхождение в сумме всплывало уже после согласования. Ниже — что именно перенесли внутрь платформы и что это изменило в цифрах.
Задача и ограничения
Личный кабинет на Velo должен был закрыть три роли: клиент, менеджер направления, администратор. Ограничения платформы задали архитектуру: расчёты нельзя держать на стороне пользователя — итоговую сумму считает только серверная функция по данным тарифа, срока и скидки, а поля суммы и статуса в интерфейсе доступны лишь для чтения. Права на уровне строк разводят доступ: клиент видит свои заявки, менеджер — заявки своего направления, администратор — все и может править тарифную сетку.
Каждое изменение пишется в отдельную коллекцию, поэтому спор «кто поменял сумму» закрывается по журналу, а не по переписке.
Результат в цифрах
- Расчёт стоимости: было 1–2 рабочих дня на ответ менеджера — стало 3–4 секунды после отправки формы.
- Доля операций без участия сотрудника: 34% → 91% — пересчёт, согласование и уведомление идут внутри кабинета.
- Обращения в поддержку по статусу заявки: минус 62% за первый квартал после запуска.
- Ошибки в суммах из-за ручного ввода: с 7–9 на сотню заявок до нуля — тариф подставляется из справочника.
Роли и расчёты перестали быть ручным процессом: менеджер занимается сделками, а не сверкой таблиц, клиент сам видит стоимость и статус. Тот же контур прав и серверной проверки сумм переносится на следующие модули кабинета без переписывания логики.
Что делать, если шаблон уже перегружен доработками
Перегруженный шаблон — это не про количество строк кода, а про связность. Сначала снимаем карту зависимостей: какие модули обращаются к одним и тем же коллекциям напрямую, сколько обработчиков висит на событиях одной страницы, где одна и та же логика продублирована с разными условиями. Модули на Velo (Wix Code) часто пишутся итеративно, и если запись в данные идёт в обход общего слоя доступа, любая правка тянет за собой переписывание соседей.
Дальше делим код на три группы. Изолированные модули с явными входами и выходами оставляем как есть — они не мешают. Модули с повторяющейся логикой выносим в единый слой и правим точечно. Всё, что завязано на состояние страницы и порядок отрисовки, переписываем целиком. Такой рефакторинг модулей идёт частями, и сайт в это время продолжает принимать заказы.
| Режим | Когда подходит | Ограничения |
|---|---|---|
| Правка на месте | 1–2 модуля, связность низкая | следующий модуль снова заденет соседей, долг накапливается |
| Поэтапный рефакторинг | шаблон живой, остановка недопустима | дольше по срокам, часть логики временно живёт в двух вариантах |
| Пересборка раздела | связность высокая, логика держится на порядке отрисовки | нужен поэтапный перенос данных и план отката |
Пересборка раздела без простоя делается рядом: новый раздел собирается на копии, данные переносятся порциями, старая версия остаётся рабочей до последнего шага. Переключение — только после прогона ключевых сценариев на копии, а откат — возврат к предыдущей конфигурации за один шаг.
Технические сомнения перед стартом
Ниже — четыре вопроса, которые чаще всего всплывают на техническом разборе перед началом работ. Ответы короткие и предметные: без обещаний «всё возможно», с указанием того, как именно обходим ограничения платформы и что делаем на стороне заказчика.
Как быть с лимитами платформы на запросы и объём данных?
Платформа задаёт квоты на число обращений к хранилищу и на время работы серверного кода. Тяжёлые выборки выносим в агрегаты и собираем их по расписанию, списки отдаём страницами, а не целиком, частые чтения закрываем кэшем. Схему хранения проектируем под эти квоты заранее — при таком подходе рост нагрузки не упирается в потолок платформы.
Что будет, когда база пользователей вырастет в разы?
Узкое место при росте — не объём записей, а запросы без индексов и выборки «всё сразу». Закладываем индексы под реальные сценарии поиска, разбиваем выдачу на страницы, длительные операции уводим в фоновую обработку с журналом выполнения. Дополнительно предусматриваем архив редко используемых записей, чтобы рабочие коллекции оставались быстрыми.
Мы зависим от внешних сервисов — что при их отказе?
Каждую интеграцию изолируем за собственным слоем: если внешний сервис не отвечает, приложение продолжает работать, а операции встают в очередь на повтор. Критичные данные сначала фиксируются у нас, потом передаются наружу, поэтому отказ сервиса не превращается в потерянные заявки или оплаты. Для замены поставщика достаточно переписать один слой, не переделывая приложение.
Как обеспечивается сохранность данных?
Настраиваем регулярное резервное копирование коллекций и проверку восстановления из копии — не сам факт бэкапа, а реально протестированный откат. Дополнительно ведём версионирование схемы: изменение структуры данных не ломает уже сохранённые записи. Доступы разграничиваем по ролям, действия с критичными данными попадают в журнал.
Опишите свой сценарий — сверим его с этими ограничениями и вернёмся с оценкой и планом работ.Обсудим задачу и вернёмся с оценкой и планом
Обсуждение задачи начинаем с исходных данных — тогда оценка опирается на факты, а не на предположения. Достаточно тестовой копии сайта и описания сценариев: доступы оформляйте с ограниченными правами, боевую среду не трогаем. Что прислать или рассказать:
- Доступ к тестовой копии проекта или экспорт структуры: страницы, коллекции данных, серверный код на Velo, настройки прав.
- Описание сценариев по шагам: регистрация, оформление заказа, расчёт, выгрузка отчёта, уведомления.
- Роли пользователей: кто что видит и меняет, где нужны ограничения по данным и история действий.
- Примеры данных: 5–10 реальных записей из коллекций — объёмы, типы полей, связи между таблицами.
- Текущие узкие места: где падает скорость, что правят руками, какие решения уже пробовали и почему отказались.
- Ограничения: внешние сервисы для обмена данными, сроки, требования к мобильной версии и пиковой нагрузке.
По этим данным возвращаемся с планом работ по этапам: подготовка тестовой среды, схема коллекций и доступов, перенос логики, проверка сценариев, публикация. Порядок приёмки фиксируем заранее — перечень проверок по каждому сценарию, прогон на тестовой копии, затем публикация и период наблюдения с разбором замечаний. Опишите задачу — вернёмся с оценкой и планом.
