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