Налаштування headless CMS на Strapi або Contentful

У нас контентний маркетинговий сайт, і стара монолітна CMS давно стала вузьким місцем. Будь-яка дрібна правка тексту перетворюється на задачу для розробника, і редактори цим виснажені. Ми хочемо перейти на сучасну headless-архітектуру і шукаємо людину, яка вже проходила цей шлях від початку до кінця. Стек відкритий: я схиляюся до Strapi, якщо нам є сенс тримати все у себе, але так само спокійно прийму Contentful, якщо керований варіант краще підходить під розмір команди та бюджет. Частина вашої роботи — допомогти нам ухвалити це рішення зі зрозумілими плюсами й мінусами, а не просто запропонувати улюблений інструмент.

Обсяг — це повноцінне робоче налаштування, а не proof of concept. Ви акуратно опишете наші типи контенту (статті, автори, категорії, блоки лендингів, повторно використовувані компоненти, медіа), задасте розумну валідацію полів і спроєктуєте зв'язки так, щоб вони були зручні редакторам, а не копіювали сиру структуру бази. Поверх цього — чисте, задокументоване API (REST або GraphQL) з пагінацією, фільтрацією та розділенням чернетка/опубліковано, і підключення його до нашого JAMstack-фронтенду, щоб сторінки рендерились із контенту CMS. Редактори мають самостійно створювати, переглядати та публікувати записи, а ролі й права повинні захищати структуру від випадкових поломок. У команді вже є дизайнер і фронтенд-розробник, тож працювати ви будете у зв'язці, а не наодинці.

Надішліть, будь ласка, приклади ваших headless-CMS проєктів і напишіть, яку платформу ви порекомендуєте для нашого випадку та чому.

— Описати типи контенту, компоненти та зв'язки під реальні редакторські процеси
— Віддати чисте REST або GraphQL API з пагінацією, фільтрами та статусами чернетка/опубліковано
— Підключити CMS до JAMstack-фронтенду та налаштувати попередній перегляд
— Налаштувати ролі й права редакторів і шлях міграції наявного контенту