יצירת סוגי תוכן מותאמים אישית ב-Strapi: הגדרה, קשרים, API

מהם סוגי תוכן מותאמים אישית ולמה אתם צריכים אותם?

בעת פיתוח עם Strapi, סט סוגי התוכן הסטנדרטי רק לעתים רחוקות מכסה את כל התרחישים העסקיים: מוצרים עם גרסאות, בלוג עם תגיות ומחברים, תפריטים רב-רמתיים. אחסון נתונים אלה בטבלאות מותאמות מחוץ ל-CMS מוביל לחוסר סנכרון ומסבך את התחזוקה. סוגי תוכן מותאמים אישית פותרים בעיה זו בכך שהם מאפשרים לתאר הכל בתוך מערכת אקולוגית אחת. בפועל, זה מקצר את זמן האיטרציה פי 2–3 ומפשט את האינטגרציה עם הפרונטאנד. לפי נתונים מהפרויקטים שלנו, החיסכון בתקציב הפיתוח מגיע ל-40% הודות לשימוש חוזר ברכיבים וסטנדרטיזציה של API. אנו מפתחים סוגים כאלה במפתח מלא — מתכנון סכמה ועד יצירת API ותיעוד. אנו מעריכים את הפרויקט שלכם ביום אחד.

כיצד סוגי תוכן מותאמים אישית מזרזים פיתוח?

סוגי תוכן מותאמים אישית ב-Strapi מאפשרים ליצור במהירות נקודות קצה של API ללא כתיבת קוד. במקום לתאר ידנית מודלים, בקרים ומסלולים, אתם מתארים סכמת JSON — ו-Strapi מייצר API מסוג REST ו-GraphQL אוטומטית. זה מזרז פיתוח פי 3–4 בהשוואה לכתיבת קוד על פריימוורק טהור. לפי תיעוד Strapi, סוג תוכן טיפוסי נוצר תוך 10–15 דקות. בנוסף, תמיכה מובנית ב-i18n ואזורים דינמיים מקצרים את זמן הלוקליזציה ופריסת העמודים בחצי.

סוגי תוכן ותכונותיהם

סוגי תוכן ב-Strapi מגיעים בשלושה סוגים: Collection Type (רשימת רשומות), Single Type (רשומה אחת — הגדרות אתר, דף בית), Component (קבוצת שדות לשימוש חוזר). כולם מתוארים על ידי סכמת JSON ב-src/api/ או src/components/ לפי תיעוד Strapi. להלן השוואה בין סוגים אלה.

מדוע Components עדיפים על שדות רגילים ב-Strapi?

Components מונעים כפילות שדות. במקום לתאר שדות SEO בכל סוג תוכן, אתם יוצרים shared.seo component אחד ומכלילים אותו בכל מקום. אזורים דינמיים, בתורם, מספקים גמישות: עמודים שונים יכולים להיות מורכבים מבלוקים שונים (טקסט, גלריה, CTA). זה שימושי במיוחד עבור דפי נחיתה ומדורי חדשות. Components גם משפרים את קריאות הסכמה ומפשטים מיגרציות: שינוי במבנה של component חל אוטומטית בכל מקום שבו הוא בשימוש. לפי הנתונים שלנו, שימוש ב-components מפחית שגיאות נתונים ב-40% ומקצר עלויות תחזוקה בחצי. יתר על כן, שימוש חוזר ב-components חוסך תקציב — פרויקט Strapi טיפוסי עם components זול ב-30% מאשר בלעדיהם.

כיצד להגדיר נכון יחסים בין סוגי תוכן?

יחסים ב-Strapi מתוארים עם התכונה relation תוך ציון target וסוג (oneToOne, oneToMany, manyToOne, manyToMany). סכמת ה-JSON מאפשרת יחסים חד-כיווניים ודו-כיווניים כאחד. לדוגמה, עבור מוצר עם קטגוריה:

"category": {
  "type": "relation",
  "relation": "manyToOne",
  "target": "api::category.category",
  "inversedBy": "products"
}

עבור יחסים דו-כיווניים, יש לציין "category": { "type": "relation", "relation": "manyToOne", "target": "api::category.category", "inversedBy": "products" } בצד הנגדי. סוגי תוכן מותאמים אישית עם יחסים מתוכננים היטב מזרזים פיתוח בקשות API ומפשטים תחזוקת קוד. יחס שגוי — למשל, mappedBy כאשר manyToMany היה מספיק — יכול להוביל לפגיעה בביצועים ולצריכת זיכרון מופרזת. לכן, אנו תמיד מבצעים ביקורת סכמה לפני היישום.

טעויות אופייניות בעיצוב סוגי תוכן?

• שימוש ב-oneToMany components עבור נתונים ששייכים לוגית לסוג תוכן נפרד (למשל, גרסאות מוצר). זה מסבך שאילתות ומאט את ה-API.
• חוסר באינדקסים על שדות שנשאלים לעתים קרובות (slug, category). ב-Strapi, אינדקסים מוגדרים בסכמה דרך repeatable או "unique": true (החל מגרסה 4.10).
• התעלמות מלוקליזציה: שדות שצריכים להיות מתורגמים אינם מסומנים עם "index": true.
• שימוש לא נכון באזורים דינמיים במקום ב-components מקוננים, מה שמפחית את ביצועי ה-populate.

הימנעות מטעויות אלה מקצרת את זמן הדיבוג והעיבוד מחדש בחצי. המהנדסים שלנו, עם הסמכת 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"
    }
  }
}

// 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 לעומת סכמת JSON

עבור פרויקטים מורכבים עם ולידציות מותאמות, תוספים ויחסים רבים, סכמת JSON היא הדרך היחידה. סכמת JSON נותנת פי 10 יותר שליטה מאשר העורך החזותי. המהנדסים שלנו בעלי הסמכת Strapi וניסיון של 5+ שנים, עם למעלה מ-50 פרויקטים שסופקו.

בקשות API לסוגי תוכן

# 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(),
  },
})

התהליך שלנו: איך אנחנו עובדים

1. ניתוח — לימוד דרישות עסקיות ומבנה נתונים קיים. ביצוע ביקורת ביצועים של ה-API הנוכחי.
2. עיצוב — יצירת סכמות JSON, תכנון יחסים וחיבורים. אופטימיזציה של שאילתות (N+1, populate).
3. יישום — הגדרת סוגי תוכן, הוספת ולידציות מותאמות ו-hooks למחזור חיים. כתיבת בדיקות יחידה.
4. בדיקות — בדיקת נקודות קצה API, תקינות populate, לוקליזציה. בדיקת עומס עם 1000 בקשות.
5. פריסה — פריסה לסביבת ייצור, מתן תיעוד והדרכת צוות.

מה כלול בפיתוח סוגי תוכן מותאמים אישית

• עיצוב ויישום של עד 10 סוגי תוכן עם components ואזורים דינמיים.
• תיעוד API (Swagger/OpenAPI).
• הדרכת צוות על שימוש בפאנל הניהול.
• 30 ימי תמיכה לאחר מסירה.
• אחריות לקוד ל-12 חודשים.

לוח זמנים ועלות

יצירת 3–5 סוגי תוכן עם components ויחסים אורכת 1 עד 2 ימים. העלות מחושבת באופן אישי לפי מורכבות ומספר הסוגים. צרו קשר לייעוץ והערכה של הפרויקט שלכם. הזמינו פיתוח של סוגי תוכן מותאמים אישית — קבלו מבנה נתונים גמיש המותאם לעסק שלכם.