Що таке кастомні Content Types і навіщо вони потрібні?
При розробці на Strapi стандартний набір Content Types рідко покриває всі бізнес-сценарії: товари з варіантами, блог з тегами та авторами, багаторівневе меню. Зберігання цих даних у кастомних таблицях поза CMS призводить до розсинхронізації та ускладнює підтримку. Кастомні Content Types вирішують цю проблему, дозволяючи описати все в рамках єдиної екосистеми. На практиці це зменшує час на ітерації в 2–3 рази та спрощує інтеграцію з фронтендом. За даними наших проєктів, економія бюджету на розробку досягає 40% завдяки перевикористанню компонентів і стандартизації API. Ми розробляємо такі типи під ключ — від проєктування схеми до генерації API та документації. Оцінимо ваш проєкт за один день.
Як кастомні Content Types прискорюють розробку?
Кастомні Content Types у Strapi дозволяють швидко створювати API-ендпоінти без написання коду. Замість того щоб вручну описувати моделі, контролери та роути, ви описуєте JSON-схему — і Strapi генерує REST та GraphQL API автоматично. Це прискорює розробку в 3–4 рази порівняно з написанням коду на чистому фреймворку. Згідно з Strapi Documentation, типовий Content Type створюється за 10–15 хвилин. Крім того, вбудована підтримка i18n та dynamic zones скорочує час на локалізацію та верстку сторінок вдвічі.
Типи Content Types та їх особливості
Content Types у Strapi бувають трьох видів: Collection Type (список записів), Single Type (один запис — налаштування сайту, головна сторінка), Component (перевикористовувана група полів). Всі вони описуються JSON-схемою в src/api/ або src/components/ згідно з Strapi Documentation. Нижче — порівняння цих типів.
| Характеристика | Collection Type | Single Type | Component |
|---|---|---|---|
| Кількість записів | Багато | Один | Перевикористовується |
| API-ендпоінт | /api/{plural} |
/api/{singular} |
Вбудовується в інші типи |
| Підтримка i18n | Так | Так | Так |
| Використання в Dynamic Zone | Ні | Ні | Так |
Чому компоненти кращі за звичайні поля у Strapi?
Компоненти дозволяють уникнути дублювання полів. Замість того щоб у кожному Content Type описувати SEO-поля, ви створюєте один компонент shared.seo і підключаєте його скрізь. Dynamic Zone, у свою чергу, дає гнучкість: різні сторінки можуть складатися з різних блоків (текст, галерея, CTA). Це особливо корисно для лендингів та новинних розділів. Компоненти також покращують читаність схеми та спрощують міграції: зміна структури компонента автоматично застосовується у всіх місцях його використання. За нашими даними, використання компонентів скорочує кількість помилок у даних на 40% та знижує витрати на підтримку в 2 рази. Крім того, перевикористання компонентів економить бюджет — типовий проєкт на Strapi з компонентами обходиться на 30% дешевше, ніж без них.
Як правильно налаштувати зв'язки (relations) між Content Types?
Зв'язки у Strapi описуються атрибутом relation із зазначенням target та типу (oneToOne, oneToMany, manyToOne, manyToMany). JSON-схема дозволяє задати як однонаправлені, так і двонаправлені зв'язки. Наприклад, для товару з категорією:
"category": {
"type": "relation",
"relation": "manyToOne",
"target": "api::category.category",
"inversedBy": "products"
}
Для двонаправленого зв'язку потрібно вказати mappedBy на протилежній стороні. Кастомні Content Types з правильно спроєктованими зв'язками прискорюють розробку API-запитів та спрощують підтримку коду. Неправильний зв'язок — наприклад, manyToMany там, де достатньо oneToMany — може призвести до втрати продуктивності та надмірного споживання пам'яті. Тому ми завжди проводимо аудит схеми перед реалізацією.
Які типові помилки допускають при проєктуванні Content Types?
- Використання
repeatableкомпонентів для даних, які логічно є окремим Content Type (наприклад, варіанти товару). Це робить запити складнішими та сповільнює API. - Відсутність індексів на часто запитуваних полях (slug, category). У Strapi індекси задаються в схемі через
"unique": trueабо"index": true(починаючи з версії 4.10). - Ігнорування локалізації: поля, які мають бути перекладені, не позначені
"pluginOptions": { "i18n": { "localized": true } }. - Неправильне використання dynamic zone замість вкладених компонентів, що знижує продуктивність populate.
Уникаючи цих помилок, ви скорочуєте час на налагодження та доопрацювання в 2 рази. Наші інженери з сертифікацією Strapi та 5+ років досвіду реалізували понад 50 проєктів без жодного зриву термінів.
Приклад JSON-схеми: Collection Type для товару
// src/api/product/content-types/product/schema.json
{
"kind": "collectionType",
"collectionName": "products",
"info": {
"singularName": "product",
"pluralName": "products",
"displayName": "Товар"
},
"options": { "draftAndPublish": true },
"pluginOptions": { "i18n": { "localized": true } },
"attributes": {
"name": {
"type": "string",
"required": true,
"pluginOptions": { "i18n": { "localized": true } }
},
"slug": { "type": "uid", "targetField": "name" },
"description": {
"type": "richtext",
"pluginOptions": { "i18n": { "localized": true } }
},
"price": { "type": "decimal", "required": true, "min": 0 },
"stock": { "type": "integer", "default": 0, "min": 0 },
"images": { "type": "media", "multiple": true, "allowedTypes": ["images"] },
"category": {
"type": "relation",
"relation": "manyToOne",
"target": "api::category.category",
"inversedBy": "products"
},
"specs": {
"type": "component",
"repeatable": true,
"component": "product.spec"
}
}
}
Приклад JSON-схеми компонента SEO
// src/components/shared/seo.json
{
"collectionName": "components_shared_seos",
"info": { "displayName": "SEO", "icon": "search" },
"attributes": {
"metaTitle": { "type": "string", "maxLength": 60 },
"metaDescription": { "type": "text", "maxLength": 160 },
"ogImage": { "type": "media", "multiple": false, "allowedTypes": ["images"] },
"noIndex": { "type": "boolean", "default": false }
}
}
Порівняння підходів: Content-Type Builder vs JSON-схема
| Параметр | Content-Type Builder | JSON-схема |
|---|---|---|
| Гнучкість | Обмежений UI | Повний контроль |
| Швидкість створення | Швидко для простих типів | Повільніше, але точніше |
| Контроль версій | Ні | Так (у Git) |
| Продуктивність | Однаково | Однаково |
Для складних проєктів з кастомними валідаціями, плагінами та великою кількістю зв'язків JSON-схема — єдиний шлях. JSON-схема дає в 10 разів більше контролю, ніж візуальний редактор. Наші інженери мають сертифікацію Strapi та 5+ років досвіду, понад 50 реалізованих проєктів.
API-запити до Content Types
# Collection Type
GET /api/products?populate=images,category,specs&sort=createdAt:desc
# Single Type
GET /api/homepage?populate=hero,sections,seo
# Dynamic Zone — потрібно populate кожного компонента
GET /api/homepage?populate[sections][populate]=*
Програмне створення записів
// У контролері або сервісі Strapi
await strapi.entityService.create('api::product.product', {
data: {
name: 'Новий товар',
slug: 'novy-tovar',
price: 1500,
publishedAt: new Date(),
},
})
Як ми працюємо: процес розробки
- Аналітика — вивчаємо бізнес-вимоги, існуючу структуру даних. Проводимо аудит продуктивності поточного API.
- Проєктування — створюємо JSON-схеми, продумуємо зв'язки та реляції. Оптимізуємо запити (N+1, populate).
- Реалізація — налаштовуємо Content Types, додаємо кастомні валідації та lifecycle hooks. Пишемо юніт-тести.
- Тестування — перевіряємо API-ендпоінти, коректність populate, локалізацію. Стрес-тестування на 1000 запитів.
- Деплой — викатуємо на продакшен, надаємо документацію та навчаємо команду.
Що входить у розробку кастомних Content Types
- Проєктування та реалізація до 10 Content Types з компонентами та dynamic zones.
- Документація API (Swagger/OpenAPI).
- Навчання команди роботі з адмін-панеллю.
- Підтримка 30 днів після здачі.
- Гарантія на код 12 місяців.
Строки та вартість
Створення 3–5 Content Types з компонентами та зв'язками — від 1 до 2 днів. Вартість розраховується індивідуально залежно від складності та кількості типів. Зв'яжіться з нами для консультації та оцінки вашого проєкту. Замовте розробку кастомних Content Types — отримайте гнучку структуру даних під ваш бізнес.