Серверна частина це місце, де записано справжні правила компанії: хто що може, що з чим несумісне, як рахується ціна, скільки повернути клієнтові в разі скасування. Усе інше, від сайту до мобільного застосунку, лише способи ці правила показати. Якщо правила живуть в інтерфейсі, у таблицях і в головах співробітників, бізнес втрачає гроші на розбіжностях і не може масштабуватися.
Це восьмий етап стратегії розробки застосунку. Розбираємо, що входить у розробку серверної частини, що Ви отримуєте, скільки це коштує і чому помилка в моделі даних обходиться дорожче за будь-яку іншу.
Що відбувається на етапі
- Розробка на PHP (Yii2).
- Робота з MySQL, оптимізація запитів, кешування (Memcached).
- Керування залежностями через Composer.
За цими рядками стоять конкретні речі: схема бази й міграції, API для інтерфейсів та інтеграцій, права доступу, розрахунки, статуси й журнал подій. Типову частину ми пришвидшуємо власним генератором Fractal: схема даних, API з документацією і базова адмінка генеруються, а вручну пишеться те, що відрізняє Ваш бізнес від сусіднього.
Що Ви отримуєте на виході
- Базу даних зі схемою, яка повторює модель із технічного завдання, і міграції для її зміни.
- API з документацією, за яким працюють інтерфейси, мобільний застосунок і зовнішні системи.
- Адміністративну панель для керування даними.
- Бізнес-правила, права доступу й розрахунки, які перевіряються на сервері під час кожної дії.
- Журнал подій: хто, що і коли зробив у системі.
Скільки коштує розробка серверної частини
У прайсі Ingello етап серверної бізнес-логіки коштує від $0 до $4700, ціну фіксуємо до початку робіт. Нижня межа означає, що окремий бюджет на етап потрібен не в кожному проєкті. Усередині діапазону ціну визначають:
- кількість сутностей, статусів і зв'язків між ними;
- скільки бізнес-правил і розрахунків: ціни, знижки, повернення, нарахування;
- скільки ролей і наскільки детально розкладено права;
- чи потрібне перенесення даних зі старої системи;
- яке навантаження очікується і де потрібен кеш.
Чому правило має бути в одному місці
Якщо умову «знижка не більше 30%» прописано в інтерфейсі, у звіті та в імпорті, то рано чи пізно ці три копії розійдуться. Одне правило, одне місце. Інтерфейс його показує, сервер його охороняє.
Те саме стосується прав доступу. Сховати кнопку недостатньо: дію має бути закрито на сервері, інакше її можна викликати напряму. Докладніше в розборі безпеки бойового контуру.
Як це виглядає на реальних проєктах
В адміністративній системі автобусного перевізника BusTicket права розкладено за ролями до рівня дій: для кожного розділу окремо «переглядати», «редагувати» і «повний доступ». Диспетчер не видалить рейс, перевізник не побачить чужих бронювань, агент не залізе в зарплати. Усе, що відбувається в системі, пишеться в хроніку. Коли за пів року хтось спитає, хто це зробив, відповіддю буде запис із датою, а не здогадка.
Там же сервер рахує повернення. Відсоток повернення береться з довідника «Умови повернення» і залежить від того, за скільки часу до відправлення скасовано поїздку. Рейс партнера потрапляє в продаж лише після модерації адміністратором.
В інтернет-магазині підлогових покриттів Lino правила інші: шість видів цін, зокрема дві стоп-ціни, нижче яких продавати не можна, і дробова кількість у кошику з точністю до двох знаків. Такі правила не можна довірити інтерфейсу: менеджер править ціни цілими категоріями, а покупець за жодних умов не має побачити ціну нижче стоп-ціни.
Налаштування без програміста
Частина правил змінюється частіше, ніж виходить нова версія. У технічному завданні платформи онлайн-тренувань XenFit окремо записали, що коефіцієнти рейтингу й частота розсилок змінюються з адмінки без програміста. Там же зафіксували вимоги до коду: назви в коді збігаються з мовою предметної області, а API документується у Swagger. Новий розробник читає такий сервер як опис бізнесу.
Дані визначають стелю продукту
Схема даних, закладена на етапі технічного завдання, тут стає кодом. Помилка у зв'язках не виправляється індексом чи кешем. Вона виправляється міграцією, а міграція на живих даних завжди дорожча, ніж роздуми на старті.
Під час перенесення даних Lino зі старої структури кожне поле розбирали окремо: у замовника виробник і бренд лежали в одній таблиці, а закупівельна ціна називалася інакше, ніж у нас. Заразом зняли зайві обмеження NOT NULL, щоб імпорт не падав на порожніх значеннях.
Коли навантаження зросте, допоможуть прийоми з матеріалу про оптимізацію сервера. Але оптимізація лікує повільний запит, а не хибну модель.
Що ламається, якщо заощадити
- Правила копіюються в інтерфейс, звіти й імпорт і розходяться між собою.
- Права закрито лише прихованням кнопок, і будь-яку дію можна викликати напряму.
- Немає журналу подій, і спірні ситуації розбирають з пам'яті співробітників.
- Кожна зміна цін чи умов потребує програміста, хоча могла б налаштовуватися в адмінці.
Що потрібно від Вас
- Правила, за якими компанія працює зараз: прайси, умови знижок і повернень, регламенти погодження.
- Перелік ролей і того, що кожній дозволено.
- Вивантаження поточних даних, якщо їх треба перенести зі старої системи чи таблиць.
Куди далі
Далі деплой та інфраструктура. Попередній крок: інтеграції. Карта всіх етапів у стратегії розробки застосунку.
Обговорити архітектуру. Якщо правила Вашої компанії зараз живуть у таблицях і головах, приходьте на безкоштовну консультацію з архітектором: розберемо модель даних, а після консультації Ви отримаєте розрахунок ціни та строків за етапами.
