מודולים מותאמים אישית ב-Directus: היכן שהיכולות המובנות אינן מספיקות
ממשק הניהול המובנה של Directus מכסה CRUD טיפוסי: קולקציות, שדות, תפקידים, הרשאות ברמת הרשומות. התקרה מתחילה היכן שמופיעה לוגיקה לא סטנדרטית בממשק הניהול — אישור בקשה בשלושה זוגות עיניים, חישוב מחדש של סטטוס כאשר רשומה מקושרת משתנה, ייצוא למערכת חשבונאית לפי אירוע.
המגבלות של קולקציות מובנות מתגלות בקשרים מורכבים: טבלאות ביניים עם לוגיקה משלהן, שדות מחושבים שלא ניתן לבטא בנוסחה, הרשאות שאינן תלויות בתפקיד אלא במצב של הרשומה עצמה.
המחיר של דרכי עקיפין גבוה ממה שנדמה. עורך מנהל מצב ידנית בשדה נפרד — במוקדם או במאוחר זה יתפצל מהמציאות. אנליסט מייצא נתונים ומאחד אותם בטבלה — הפעולה חוזרת על עצמה כל שבוע ותלויה באדם.
אוטומציה של פעולות ידניות באמצעות סקריפטים חיצוניים לפי לוח זמנים עובדת, עד שנדרשת תגובה לפעולת משתמש בתוך ממשק הניהול.
מודולים מותאמים אישית ב-Directus פותרים זאת ברמת הרחבת הפלטפורמה: ממשק משלך בממשק הניהול, נקודות קצה משלך, hooks על אירועי קולקציות, בדיקות הרשאות מותאמות אישית. הלוגיקה חיה לצד הנתונים ומנוהלת בגרסאות יחד איתם, ולא בסקריפט זר. הממשק המובנה נשאר — הצוות לא צריך ללמוד מחדש.
בהמשך נבחן כיצד זה מכוסה: אילו נקודות הרחבה אנו משתמשים בהן, מה משאירים על מנגנונים מובנים והיכן עובר הגבול בין הגדרה לקוד.
מה נותן מודול מותאם אישית: אפקט במספרים ובמצבי עבודה
מודולים מותאמים אישית של Directus נותנים אפקט מדיד במקום שבו הממשק הסטנדרטי מאלץ את העורך לעבור בין שלושה מסכים בשביל פעולה אחת. המודול מרכז את התרחיש למסך אחד: שליפת רשומות מקושרות, פעולה גורפת, ולידציה בכניסה.
פעולה טיפוסית כמו «להעביר אוסף למדור אחר עם בנייה מחדש של קשרים» מתקצרת מ-15–20 דקות של עבודה ידנית ל-40–60 שניות — ומפסיקה להיות תלויה בשאלה אם העורך זוכר את סדר השלבים.
היכן האפקט נראה מיד
- פעולות גורפות. עריכה מרוכזת של 200+ רשומות בפעולה אחת במקום עריכה אחת-אחת — הפעולות הידניות מצטמצמות בסדר גודל.
- ולידציה בכניסה. בדיקות של שדות וקשרים ברמת המודול חוסמות נתונים פגומים לפני הכתיבה למסד הנתונים, ולא אחרי הפרסום.
- תפקידים והרשאות. ממשק לתפקיד ספציפי: העורך רואה רק את השדות שלו, המנהל — את שדות השירות. פחות שגיאות הרשאה.
- אינטגרציות. מקור חיצוני נמשך לאותו מסך, העורך לא מחליף בין מערכות.
השוואה בין גישות להרחבה
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| הרחבת הממשק הסטנדרטי | תיקונים ממוקדים: שדה, רמז, סדר בלוקים | לא מתמודדת עם תרחישים מורכבים ופעולות גורפות |
| מודול נפרד | תהליך עבודה ייעודי, כמה קולקציות מקושרות, תפקידים | דורש תמיכה בקוד בעת עדכוני הפלטפורמה |
| שירות חיצוני | הלוגיקה חיה מחוץ ל-CMS, תורים וחישובים משל עצמו | כפילות גישה, סנכרון הרשאות מורכב יותר |
הבחירה נקבעת לפי תדירות הפעולה: אם התרחיש מבוצע מדי יום ונוגע בכמה קולקציות — מודול נפרד מכסה את עלות התמיכה. אם התיקון חד-פעמי — הרחבת הממשק הסטנדרטי מספיקה.
Directus מחזיק הרחבות כחבילות מבודדות, ולכן המודול מתעדכן בנפרד מהליבה ואינו חוסם מעבר לענף העדכני. תארו את התרחיש שלכם — נחזור עם הערכה ותוכנית, איזו אפשרות הרחבה סוגרת את המשימה עם תמיכה מינימלית.
כיצד אנו מתכננים ומטמיעים מודול: שלבי העבודה ההנדסית
מודולים מותאמים אישית של Directus אנו בונים כשכבה נפרדת הניתנת להרחבה מעל הליבה: היא אינה נוגעת בטבלאות הסטנדרטיות ומתעדכנת באופן בלתי תלוי בפלטפורמה. לכן התהליך מתחיל לא בקוד, אלא בניתוח המשימה ותכנון סכמת הנתונים — ממנה תלויים גם ההרשאות וגם ביצועי השאילתות.
- ניתוח המשימה וגבולות המודול. אנו מגדירים אילו ישויות הוא מוסיף, עם אילו קולקציות ליבה הוא מקושר, ומה הוא חושף החוצה דרך API. התוצר — סכמת אינטראקציה מוסכמת, ולא "תעשו את זה יפה".
- תכנון סכמת הנתונים. אנו מתארים קולקציות, קשרים, שדות מחושבים ואינדקסים. בנפרד אנו בודקים היכן נדרש cascade בעת מחיקה, והיכן — מחיקה רכה, כדי שהדיווח לא יאבד היסטוריה.
- הגדרת הרשאות גישה. תפקידים, מדיניויות וכללים ברמת השדות והשורות: מי רואה, מי משנה, ומה נגיש רק דרך לוגיקה בצד השרת. את ההרשאות אנו מתארים באופן דקלרטיבי ומגרסאים יחד עם הקוד.
- מימוש וחיבור hooks. הלוגיקה חיה בשכבת השירות של המודול, ולא במטפלים מפוזרים — כך ניתן לבדוק אותה ולעשות בה שימוש חוזר בפרויקטים אחרים.
- בדיקה על עותק של מסד הנתונים. אנו מריצים מיגרציות ותרחישים על תמונת מצב של נתונים אמיתיים: נפחים, מקרי קצה, התנגשויות הרשאות. זה תופס בעיות שאינן נראות על מסד נתונים ריק.
- מסירה ותיעוד. אנו מוסרים תיאור סכמה, מטריצת הרשאות, הוראות פריסה וחזרה לאחור. צוות הלקוח יכול לפתח את המודול בלעדינו.
כל שלב מסתיים בארטיפקט שניתן לבדוק: סכמה, מטריצת גישה, דוח ריצה על העותק. כך המודול נשאר צפוי בעת עדכוני הליבה ואינו הופך לפורק שאין לתחזק אותו.
במה שונה מודול מותאם אישית מקבוצת hooks ושירות חיצוני?
Hooks ואוטומציות הם תגובה לאירוע בתוך המערכת: רשומה נוצרה, עודכנה, נמחקה. הם זולים בפיתוח ואינם נוגעים בממשק, אך חיים בצל: המשתמש אינו רואה מה קורה, אינו יכול להפעיל את הלוגיקה ידנית ואינו מקבל משוב, מלבד רשומה ביומן. כל עוד התרחיש מצטמצם ל"כאשר שדה משתנה, לחשב מחדש ערך מקושר", די ב-hooks, ואין טעם להקים מודול.
מודול מותאם אישית נדרש במקום שבו מופיע מסך עבודה משלו בתוך ממשק הניהול: פעולות מרובות על מבחר, אשף שלב-אחר-שלב, סיכום לפי פרויקט, אישור עם תפקידים. הסימן המרכזי — העובד צריך ללחוץ על משהו ולראות תוצאה, ולא להמתין שהמערכת תגיב מעצמה לשינוי ברשומה.
הרחבת ממשק הניהול מעניקה הרשאות גישה משלה, ניווט משלה ובידוד: הלוגיקה של המודול אינה מרוחה על פני עשרה hooks, רואים אותה בשלמותה וניתן להעביר אותה למהנדס אחר.
שירות חיצוני מנצח בדבר אחר: כאשר העומס אינו אמור ליפול על האפליקציה, כאשר נדרשים תורים משלהם, חישובים כבדים או אינטגרציה עם מערכות זרות לפי לוח זמנים. אך יש לו מחיר משלו — קו פריסה נפרד, סנכרון נתונים ונקודת כשל, שעליה שוכחים עד הפער הראשון. שירות חיצוני מול מודול — זו בחירה בין "לוגיקה לצד הנתונים" ל"לוגיקה לצד העומס".
בפועל הגבולות כאלה: hooks — לתגובות לאירועים, מודול — לעמדות עבודה בתוך ממשק הניהול, שירות חיצוני — לעיבוד כבד ורקעי. לעתים קרובות כל השלושה מתקיימים יחד: המודול מפעיל פעולה, ה-hook מתעד את השינוי, והשירות החיצוני מביא משימה ארוכה עד הסוף.
טעות היא לנסות לכסות ב-hooks את מה שהוא במהותו ממשק: מתקבלת קבוצה של כללים בלתי נראים, שאיש לא יתמצא בהם כעבור חצי שנה.
לכן אנו מתחילים מניתוח התרחיש, ולא מבחירת הכלי. אם המשימה נתקלת בפעולות של העובד — מתכננים מודול; אם בתגובה לנתונים — מסתפקים ב-hooks; אם בהיקף החישובים — מוציאים החוצה. תארו את המשימה — נחזור עם הערכה ותוכנית, שבה יהיה ברור מה בדיוק מרחיבים ולמה.
מקרה בוחן: מודול לפעולות מרובות במקום עבודה ידנית בממשק הניהול
הלקוח — רשת חנויות קמעונאיות עם קטלוג של כמה עשרות אלפי כרטיסים — הגיע עם כאב קונקרטי: מנהלי תוכן סימנו מאפיינים ידנית והעבירו מוצרים בין מדורים דרך ממשק הניהול.
פעולה אחת על קבוצה של 400 פריטים ארכה למפעיל כשלוש שעות, בוצעה במספר מעברים וסיפקה באופן עקבי 5-8% שגיאות: חלק מהכרטיסים נותרו עם המאפיין הישן, וחלק עברו למדור הלא נכון. השגיאות צפו כבר בחלון הראווה — היה צורך לבצע שחזור ידני ולהצליב את הייצוא.
מה עשינו
כתבנו מודול מותאם אישית לפעולות מרובות בממשק הניהול: בחירה לפי סינון, עיבוד באצוות במנות, תצוגה מקדימה של השינויים לפני ההחלה ויומן לכל כרטיס. המפעיל רואה כמה פריטים ייכללו בכלל ומאשר בפעולה אחת — במקום מעבר ידני על כל אחד.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| זמן הפעולה על 400 פריטים | ~3 שעות | 4-6 דקות |
| שיעור השגיאות בהעברה | 5-8% | <0.5% |
| שחזור קבוצה | ידני, לפי יומן הייצוא | בפקודה אחת מההיסטוריה |
המעברים הידניים נעלמו, ואיתם — סוג השגיאה "שכחתי להסיר את המאפיין הישן". היומן מספק מעקב: רואים מי, מתי ומה שינה — זה סוגר גם את חקירת התקלות וגם את שאלות ההרשאה.
המודול נבנה על ההרחבה המובנית Directus, ולכן עדכוני הליבה אינם שוברים את הלוגיקה, וההרשאות עוברות בירושה מהתפקידים הקיימים.
תאימות, מיגרציה וחזרה לאחור: מה מבהירים לפני ההתחלה
לפני ההתחלה מקבעים שלושה דברים: על איזה ענף Directus פועל הפרויקט שלכם, כיצד בנויה סכמת האוספים ומי בעל גישה לפאנל הניהול.
מודולים מותאמים אישית של Directus מרחיבים את הליבה דרך נקודות ההרחבה הרגילות, ולכן את התאימות לגרסה הנוכחית בודקים ראשונה — אם הפרויקט על ענף ישן, מתכננים תחילה עדכון ל-LTS העדכני, אחרת המודול פשוט לא ייבנה.
בנפרד בודקים אילו הרחבות כבר מותקנות: התנגשות של שני מודולים על אותו hook שוברת את פאנל הניהול כולו, וזול יותר לתפוס זאת בשלב הבדיקה מאשר בפרודקשן.
מיגרציית נתונים היא המקור השני להפתעות. אם המודול מוסיף שדות או קשרים, מכינים מיגרציה הפוכה: סקריפט העברה, בדיקת שלמות על עותק של בסיס הנתונים ונקודת חזרה.
תוכנית החזרה לאחור מתוארת לפני שורת הקוד הראשונה — איזה ארטיפקט מחזירים לאחור, מה עושים עם הסכמה, כמה זמן לוקח לחזור למצב תקין.
מה אם הפרויקט על build לא סטנדרטי? מנתחים את התצורה, מקבעים את הסטיות מהתקני ומכניסים אותן לתוכנית העבודה — בלי הפתעות בתהליך.
מה אם בסיס הנתונים גדול? מעבירים על replica, משווים את מספר הרשומות והקשרים, ורק אחר כך נוגעים בפרודקשן.
האם ניתן להחזיר את המודול לאחור בלי לעצור את השירות?
כן, אם המודול מבודד ואינו משנה אוספים קיימים. פורסים דרך קונטיינר נפרד, מעבירים את התעבורה, ושומרים את הגרסה הישנה מוכנה לחזרה. אם המודול נוגע בסכמה — מתאמים חלון זמן ועושים גיבוי לפני השינוי.
הלקוח מקבל לידיו:
- תצורת המודול וסכמת האוספים עם תיאור הקשרים;
- סקריפטים למיגרציה ולחזרה לאחור עם הוראות הרצה;
- מטריצת הרשאות ותפקידים: מי רואה מה ומה משנה;
- תיעוד להתקנה, עדכון ואבחון;
- צ'קליסט בדיקה לאחר הפריסה ואנשי קשר להסלמה.
תארו את המשימה שלכם — נחזור עם הערכה ותוכנית עבודה.
לוחות זמנים ליישום המודול לפי שלבים
לוחות הזמנים אינם תלויים בהיקף הקוד, אלא במספר הלא-נודעים: כמה ישויות המודול נוגע בהן, האם קיימות מערכות חיצוניות לאינטגרציה, ועד כמה מחמירות הדרישות להרשאות גישה.
להלן לוחות זמנים משוערים לפי שלבים עבור מודול טיפוסי — מודולים מותאמים אישית ב-Directus נבנים מהרחבות מוכנות, ולכן ההערכה נכנסת למסגרת צפויה.
הפער בפיתוח נקבע על ידי האינטגרציות: מודול בתוך ממשק הניהול נבנה מהר יותר ממודול עם סנכרון נתונים למערכת חיצונית וכתיבה חזרה. אם חלק מהלוגיקה כבר מכוסה על ידי יכולות הפלטפורמה הסטנדרטיות, שלב התכנון מתקצר, והפיתוח עובר לשכלול הממשק וההרשאות.
במקביל לפיתוח מתנהלת הכנת סביבת הבדיקות — זה חוסך יום-יומיים מהיישום. בפועל, את לוחות הזמנים מזיז לא הקוד, אלא תיאום סכימת הנתונים: כל עוד הקולקציות והקשרים לא מקובעים, אסור להתחיל בפיתוח, אחרת העבודות מחדש אוכלות את הרווח.
הערכה ניתנת לאחר ניתוח המשימה — עם תוכנית עבודה לפי שלבים והנחות שעליהן תלוי לוח הזמנים.
תאימות לתשתית הקיימת של הלקוח
מודולים מותאמים אישית של Directus אינם דורשים מעבר לפלטפורמה חדשה: הם מתחברים למופע שלכם כהרחבות ופועלים מעל סכימת הנתונים הנוכחית. להלן — אפשרויות פריסה טיפוסיות שאליהן אנו מחברים את המודולים, ומגבלות שכדאי לראות לפני ההתחלה מאשר בשלב ההשקה.
בנפרד אנו בודקים את הסטאק הקיים: מערכת ניהול בסיס הנתונים והענף המז'ורי שלה, שיטת האימות (ספק חיצוני, LDAP, SSO), אחסון הקבצים (מקומי, תואם S3), ה-reverse proxy ומדיניות הגיבוי.
מודול שכותב ישירות לבסיס הנתונים בעקיפת שכבת הגישה שובר הרשאות וביקורת — לכן כל הפעולות עוברות דרך הממשקים התקניים של הפלטפורמה.
Directus נשאר הליבה, והמודול — הרחבה: עדכון הפלטפורמה אינו הופך לשכתוב הלוגיקה. תארו את אפשרות הפריסה שלכם ואת הסטאק הנוכחי — נחזור עם הערכת תאימות ותוכנית עבודה.
