Створення сайту на Next.js у м. Миколаїв — розділення шарів

У багатьох старих проєктах вигляд сторінки й робота з базою переплетені в одному файлі, і будь-яка правка стає ризикованою. Тут інтерфейс і джерело даних розведені: змінити вигляд розділу можна, не торкаючись логіки, і навпаки.

Стек
Next.js, React
Шари
Розділені
Запуск
Етапами
Схема фронтенд-архітектури: компоненти, рендеринг, API-інтеграції та збірка для продакшенуКОМПОНЕНТИРЕНДЕРИНГAPICMSBUILDTYPESCRIPT · ІНТЕГРАЦІЇ · PERFORMANCE

Коли розділення
економить час

  • Дизайн змінюватимуть

    Вигляд оновлюють частіше за логіку.

  • Джерело даних зміниться

    Облік чи CMS планують замінити.

  • Кілька виконавців

    Дизайн і бекенд роблять різні люди.

  • Поетапний запуск

    Розділи виходять один за одним.

Як розводяться
частини проєкту

Межа між шарами описується договором про дані, а не звичкою розробника.

  • Шар даних

    Звідки й у якому вигляді береться вміст.

  • Шар логіки

    Правила обробки й перевірки.

  • Шар інтерфейсу

    Компоненти й сторінки.

  • Контракт

    Опис полів, узгоджений між шарами.

  • Межі відповідальності

    Хто що змінює без узгодження.

Що це дає
на дистанції

  • Локальні зміни

    Правка не тягне за собою решту.

  • Заміна джерела

    CMS змінюється без переверстки.

  • Паралельна робота

    Дизайн і бекенд ідуть одночасно.

  • Простіша перевірка

    Кожен шар тестується окремо.

Питання про
будову проєкту

  • Чи не робить розділення проєкт дорожчим?

    На старті — трохи, бо треба описати межі між шарами. На проєкті, який розвиватимуть роками, це повертається: більшість змін торкається одного шару, а не всього коду одразу.

  • Чи можна залишити наявну базу даних?

    Зазвичай так. Інтерфейс звертається до неї через описаний обмін, і сама база при цьому не переїжджає. Зміни в ній потрібні лише тоді, коли поточна структура не дає видати потрібні дані.

  • З чого починається перший етап?

    З одного повного сценарію — від відкриття сторінки до збереження результату. Він перевіряє контракт між шарами на практиці, і далі решта розділів будується вже за перевіреною схемою.

  • Чи можна змінити дизайн без переробки логіки?

    Так, поки набір даних лишається тим самим. Якщо ж новий дизайн вимагає полів, яких раніше не було, зміни торкнуться й шару даних — це нормально, просто планується заздалегідь.

Опишемо будову проєкту для вашої компанії в Миколаєві

Розкажіть, що вже працює й що планують міняти, — запропонуємо, як розвести це на шари.