אינטגרציה של Directus עם React נשברת על מטמון והרשאות גישה
אינטגרציה של Directus עם React כמעט לעולם לא נשברת בשלב של "קיבלנו את הנתונים והצגנו אותם". הכשל הראשון מגיע מאוחר יותר: עורך התוכן מעדכן חומר בממשק הניהול, והפרונטאנד עוד ממשיך להגיש את הגרסה הישנה מהמטמון במשך יממה שלמה.
הסיבה — הנתונים נמשכים ישירות מהדפדפן ומקוטלגים במטמון ברמת ה-CDN או ברמת הכלי לבנייה, בלי לקשור את ביטול התוקף לאירוע שינוי הרשומה. בסופו של דבר חוסר הסנכרון בין ממשק הניהול לאתר נמשך עד לשחרור הגרסה הבא, ולא עד לעריכה הבאה.
הכשל הטיפוסי השני — הרשאות גישה. כאשר בקשות ל-Directus יוצאות מקוד צד הלקוח, לתוצר הבנייה נכנס טוקן סטטי עם הרשאות רחבות: הוא גלוי בקוד המקור של העמוד ופותח גישה לקולקציות שאסור למשתמש לראות.
תפקיד ציבורי ב-Directus צריך להחזיר רק שדות ורשומות מורשים, וכל מה שדורש אימות עובר דרך שכבת שרת של האפליקציה, שבה הטוקן לא יוצא מהתשתית.
הבעיה השלישית — כפילות בקשות. רכיבי React בזמן הידרציה והרכבה מחדש פונים לאותו נקודת קצה כמה פעמים, וקריאות ישירות מהדפדפן לא עוברות דרך שכבת מטמון משותפת. בתעבורה עמוסה זה הופך לעומס מיותר על Directus ולמצב שונה אצל רכיבים שממתינים לאותם נתונים.
כל שלושת הכשלים נמצאים במישור אחד: הגבול בין הלקוח לשרת נמצא במקום הלא נכון. נבחן כיצד זה נסגר ברמת הארכיטקטורה, ולא באמצעות טלאים נקודתיים.
מה נותן השילוב של Directus ו-Next.js בפועל
מהירות הבנייה והזמן עד לתוכן הראשון
Directus מספק תוכן דרך API, ו-Next.js לוקח אותו בשלב הבנייה: עמודי קטלוג, מאמרים ודפי נחיתה נבנים כסטטיים ומוגשים מקצה הרשת. בפועל זה נותן זמן עד לתוכן הראשון בסדר גודל של עשיריות שנייה במקום שניות בעת פנייה למסד הנתונים בכל תצוגה.
רגנרציה אינקרמנטלית משנה את התמונה: בעת עריכת חומר נבנה מחדש רק העמוד המושפע, ולא כל האתר, ולכן הפרסום אורך שניות ולא דקות.
סוג התקלות שנעלם
כאשר הפרונטאנד פונה ישירות למסד הנתונים, נפילה של האחסון או שאילתה כבדה מפילות את כל האתר. עם הפרדת שכבות, התקלה מוגבלת: הסטטי המוכן ממשיך להיות מוגש מהמטמון, והכשל נוגע רק לעדכון התוכן.
זה מעביר את התקלה מ"האתר למטה" ל"עדכונים יחכו" — סוג עקרוני אחר של אירועים ונפח עבודה אחר עבור משמרת התורנות.
ביצועים תחת עומס
עמודים סטטיים אינם מעמיסים על האפליקציה בעת שיאי כניסה: גידול בתעבורה נתקע בהגשת קבצים, ולא בפניות למסד הנתונים. מודל הנתונים והרשאות הגישה מתוארים ב-Directus פעם אחת, והפרונטאנד מקבל מבנים מוכנים — פחות קוד לניתוח תגובות ופחות אי-התאמות בין ממשק הניהול לאתר.
עדכון התוכן אינו דורש פריסה של גרסת אפליקציה חדשה, ולכן השיווק והמערכת עובדים ללא תלות במחזור השחרורים של הפיתוח.
מצבי עבודה: סטטי, בנייה מחדש אינקרמנטלית, זרם חי
Directus מספק תוכן דרך API, אך אופן אספקת התוכן הזה לפרונט קובע עד כמה מהר עריכה במערכת הניהול הופכת לגלויה למבקר וכמה עומס נופל על השרת.
בפועל בוחרים בין שלושה מצבים — ולעיתים קרובות משלבים אותם באותו עמוד: קטלוג נבנה באופן סטטי, כרטיס מוצר מתעדכן באופן אינקרמנטלי, ובלוק מלאי נטען בזרם חי.
| מצב | מתי מתאים | מגבלות |
|---|---|---|
| סטטי | דפי נחיתה, תיעוד, עמודים עם עריכות נדירות | בנייה מחדש מלאה בכל שינוי; התוכן מתיישן בין בניות |
| בנייה מחדש אינקרמנטלית | קטלוגים, בלוגים, עמודים עם עדכון תכוף אך לא מיידי | נדרשים Webhooks מ-Directus; השהיה בין עריכה לפרסום; קשה יותר לנפות באגים במטמון |
| זרם חי | מונים, סטטוסים, צ'אטים, מלאי במחסן | דורש חיבור מתמיד; אינו מאונדקס על ידי מנועי חיפוש; יקר יותר בעומס |
סטטי מעניק זמן תגובה מינימלי ועומס צפוי, אך כל עריכה משמעה בנייה מחדש של כל האתר. בנייה מחדש אינקרמנטלית מסירה את המגבלה הזו: Webhook מ-Directus על אירוע פרסום בונה מחדש רק את העמודים המושפעים, והשאר נשארים במטמון.
זרם חי סוגר תרחישים שבהם הנתונים משתנים בין בניות מחדש — אך אין לעשות בו שימוש כבסיס לעמודים שאמורים להופיע בתוצאות חיפוש.
בחירת המצב היא פשרה בין רעננות התוכן, העומס ומורכבות התחזוקה. טעות בשלב הזה מתגלה מאוחר יותר: או שהעורך ממתין לפרסום שעות, או שהשרת אינו עומד בבניות מחדש בכל שמירה. נבחן כיצד להתאים מצב לאזור ספציפי באתר.
כיצד אנו מיישמים אינטגרציה: מביקורת ועד מסירה
היישום מתחיל בביקורת, לא בקוד. בשלב זה אנו מנתחים את הסטאק הנוכחי, בוחנים היכן נמצאים הנתונים וכיצד הם מגיעים לפרונטאנד, אילו מדורים מתעדכנים לעתים קרובות יותר מאחרים ומי מצוות הלקוח יעבוד עם התוכן.
הביקורת מספקת מפת צווארי בקבוק: כפילות נתונים בין שירותים, ייצוא ידני, עמודים שנבנים מחדש במלואם בגלל עריכה אחת. בלי המפה הזו כל אינטגרציה הופכת לשכתוב באקראי.
לאחר מכן אנו מתכננים את סכמת הנתונים — קולקציות, קשרים, הרשאות גישה לפי תפקידים, שדות עם ולידציה. הסכמה נקלטת לפני ההגדרה, כי שינוי שלה לאחר חיבור הפרונטאנד יקר פי כמה.
- ביקורת. מיפוי מלאי של מקורות נתונים, נקודות אינטגרציה ותרחישי עורך. בפלט — רשימת צווארי בקבוק עם עדיפויות.
- סכמת נתונים. מודל קולקציות, סוגי קשרים, תפקידים ומדיניות גישה, כללי ולידציה בצד ה-API.
- הגדרה. חיבור שכבת הנתונים לאפליקציה, מצבי מסירת תוכן, מטמון וביטול תוקף לפי אירועי שינוי.
- בדיקה. בדיקות על שליפה, הרשאות, התנהגות כאשר המקור אינו זמין; הרצת תרחישי עורך מטיוטה ועד פרסום.
- מסירה. הרשאות גישה, סביבות, הנחיות לצוות התוכן ולמפתחים, סקירה של פעולות אופייניות.
- תמיכה שוטפת. ניטור שגיאות אינטגרציה, עדכוני סכמה למדורים חדשים, תגובה לשינויים בעומס.
כל שלב מסתיים בארטיפקט שניתן לבדוק: מפת אינטגרציות, תיאור הסכמה, קונפיגורציית סביבות, דוח בדיקות. זה מסיר את הסיכון המרכזי — כאשר לאחר ההשקה אף אחד לא מבין מדוע העמוד מציג נתונים מיושנים. המסירה כוללת לא רק תיעוד, אלא גם סקירה משותפת: הצוות שלכם צריך לדעת להוסיף שדה או מדור בלעדינו.
תארו את המשימה — נחזור עם הערכה ותוכנית לפי השלבים הללו.
תוצרי פלט: קונפיגורציות, סכמות, נהלים
אינטגרציה של Directus עם הפרונטאנד היא לא "הגדרנו ושכחנו": קונפיגורציית הקולקציות, התפקידים, ההרשאות על השדות והוובהוקים חיים בריפוזיטורי ומשתנים יחד עם המוצר.
לכן בפלט אתם מקבלים לא אוסף של הגדרות מפוזרות באדמין, אלא ערכה משוחזרת שלפיה ניתן לפרוס את האינטגרציה מחדש, להעביר לצוות אחר או להרחיב בלי ארכיאולוגיה.
- קונפיגורציית סכמת Directus — קולקציות, שדות, קשרים וטיפוסים כקבצים דקלרטיביים בריפוזיטורי: הסכמה עולה על סביבה נקייה בפקודה אחת, ולא נבנית ידנית.
- סכמות נתונים וקשרים — דיאגרמה של קולקציות, כיווני קשרים ומחיקות מדורגות: רואים מה יקרה לרשומה בעת מחיקת ההורה, לפני שזה יקרה בפרודקשן.
- מדיניויות גישה — תפקידים, הרשאות על קולקציות ושדות בודדים, כללי סינון ברמת השורות: עורך רואה רק את החומרים שלו, ה-API הציבורי מחזיר רק את מה שפורסם.
- קונפיגורציית בנייה וקאש — כללים לרגנרציה אינקרמנטלית של עמודים ואילו שינויי תוכן מפעילים אותה: עריכה ב-Directus מעדכנת את העמודים הנדרשים, ולא את כל האתר.
- הגדרות וובהוקים ו-real-time — אילו אירועי פרסום מפעילים את הפרונטאנד, באיזו השהיה התוכן מגיע למבקר וכיצד מטופל אירוע שלא נמסר.
- נהל עבודה עם תוכן — אילו שדות הם חובה, מה נבדק לפני פרסום, כיצד נוצרת ישות חדשה: העורך לא שובר את הפריסה, כי הכללים מוטבעים בסכמה.
- תיעוד האינטגרציה — מפת נקודות קצה, משתני סביבה, סדר הפריסה והחזרה לגרסה קודמת של הסכמה.
- הוראות תפעול — מה לעשות בעת אי-סנכרון קאש, כיצד להוסיף שדה בלי השבתה ולאן להסתכל בעת שגיאת גישה.
כל תוצר מנוהל בגרסאות יחד עם הקוד: שינוי הרשאות או סכמה עובר ביקורת ומוחזר בדיוק כמו ריליס רגיל. תארו את המשימה שלכם — נחזור עם הערכה ותוכנית, אילו מהמסמכים והקונפיגורציות האלה נדרשים דווקא לכם.
מקרה בוחן: איך הסרנו את חוסר הסנכרון של התוכן והאצנו את הבנייה
מה היה לפני השינויים
הפרויקט — פורטל מדיה עם קטלוג ומדור מערכת: מנהלי התוכן ערכו חומרים בממשק הניהול, והפרונטאנד נבנה לפי לוח זמנים. העריכות לא הגיעו לפרודקשן עד למחזור הבא — בממוצע 40 דקות המתנה, ובמקרי פרסום דחוף המערכת שכפלה את החומר ידנית.
חוסר הסנכרון בין מה שהעורך ראה בממשק לבין מה שהאתר הציג הגיע ל-15% מהעריכות בשבוע: חלק מהשינויים אבדו בעת הכתיבה מחדש, וחלק הגיעו לפרודקשן בצורה חלקית.
הבנייה ארכה 11 דקות ובנתה מחדש את כל האתר בגלל עריכה אחת בכרטיס מוצר. החזרות אחורה קרו 2-3 פעמים בשבוע: צוות התוכן לא יכול היה לחזות מה בדיוק ייכנס לריליס, וביקש להחזיר את המצב הקודם.
מה שינינו
העברנו את הפרונטאנד לבנייה מחדש אינקרמנטלית: עריכה בקולקציה מסומנת בתג, ורק העמודים שמשתמשים בה נבנים מחדש. בנייה מלאה נשארה לשינויים בתבניות ובניווט. במקביל הגדרנו זרימת עדכונים מממשק הניהול לפרונטאנד — העורך רואה את התוצאה מיד לאחר השמירה, בלי להמתין למחזור.
הוספנו כלל החזרה אחורה: כל ריליס מקושר לתמונת מצב של התוכן, וניתן לחזור למצב הקודם בפעולה אחת. לוגי הבנייה והפרסומים אוחדו לפאנל אחד — רואים איזו עריכה גרמה לבנייה מחדש וכמה זמן היא ארכה.
מה נהיה
| מדד | לפני | אחרי |
|---|---|---|
| זמן בנייה לאחר עריכה | 11 דקות | 40-60 שניות |
| שיעור חוסר הסנכרון של עריכות | עד 15% | פחות מ-1% |
| החזרות אחורה בשבוע | 2-3 | בודדות, לפי ריליסים מתוכננים |
| השהיית פרסום | עד 40 דקות | שניות |
הבנייה הואצה בזכות הוויתור על בנייה מלאה: כעת נבנה מחדש רק האזור שנפגע. חוסר הסנכרון נעלם כי מקור האמת הוא אחד — ממשק הניהול, והפרונטאנד מקבל שינויים בזרימה ולא בחבילה לפי לוח זמנים. הכשלים הפסיקו להיות חירום: תמונת מצב של התוכן מאפשרת לחזור למצב תקין בלי השוואה ידנית.
הסטאק כאן משני — מה שחשוב הוא הסכמה: מקור תוכן אחיד, בנייה מחדש ממוקדת והחזרה אחורה צפויה. גישה כזו עוברת לקטלוגים, לדפי נחיתה ולאזורים אישיים, שבהם התוכן משתנה לעתים קרובות יותר מהקוד.
במה שונה בנייה מחדש אינקרמנטלית מזרם חי?
בנייה מחדש אינקרמנטלית וזרם חי פותרים משימה אחת — להעביר תוכן טרי לעמוד מוכן — אך בנויים אחרת ונשברים אחרת. בנייה מחדש אינקרמנטלית פועלת בצד השרת: כאשר חומר משתנה, מסומן רק אותו עמוד שתלוי בו, והוא נבנה מחדש ברקע, בעוד המבקרים מקבלים את הגרסה הקודמת מהמטמון.
זרם חי מחזיק חיבור בין הדפדפן למקור הנתונים פתוח ומחליף את הבלוק ישירות בממשק, ללא רענון וללא מעורבות מטמון השרת.
מכאן ההבדל העיקרי — ברגע העדכון. בנייה מחדש אינקרמנטלית נותנת השהיה של מספר שניות עד דקה: התוכן משתנה לעיתים רחוקות, אך העמוד מוגש כסטטי ועומד בעומס.
זרם חי מעדכן נתונים באופן מיידי, אך כל חיבור פתוח הוא משאב שצריך ללוות, ובמקרה של ניתוק החיבור הממשק חייב להציג נכון נתונים מיושנים, ולא ריק.
בחירת המצב נקבעת על פי טבע התוכן, ולא על פי נוחות המפתח. קטלוג, בלוג, לנדינג, תיעוד — זוהי בנייה מחדש אינקרמנטלית: החומר משתנה לפי לוח זמנים, וחשובים מהירות ההגשה ועמידות בפני עומסי שיא.
לוחות ניטור, צ'אטים, סטטוסי הזמנות, עריכה משותפת — זרם חי: כאן ערך מיושן על המסך יקר יותר מעלות החיבור.
בפועל המצבים כמעט תמיד מתקיימים במקביל באותו אתר. החלק הסטטי נבנה באופן אינקרמנטלי, ובלוקים נפרדים נרשמים לזרם חי דרך רכיב צד לקוח — כך העמוד נשאר מהיר, והנתונים הקריטיים לא מפגרים.
אנו מפרידים בין האזורים הללו בשלב תכנון סכימת הנתונים, כדי לא לבנות מחדש את כל העמוד בגלל מונה אחד ולא למשוך חיבור חי לשם שבו תספיק בנייה מחדש.
ספקות טכניים נפוצים בעת אינטגרציה של Directus
לפני תחילת הפרויקט כמעט תמיד עולים אותן שאלות: האם מערכת חיצונית תהפוך לנקודת כשל, האם תעמוד בעומס שיא, והאם באמת ניתן לנטוש אותה בלי לכתוב מחדש את הפרונטאנד. להלן ניתוח של כל אחת מהן, מהצד ההנדסי.
אבטחה: האם השירות החיצוני יקבל גישה לנתונים שלנו?
הגישה מופרדת ברמת התפקידים והקולקציות: לתפקיד ציבורי ניתנים רק השדות שבאמת נחוצים לפרונטאנד, והשאר סגור. טוקנים לבקשות שרת מתקיימים במשתני סביבה ואינם נכנסים לבאנדל בצד הלקוח — הדפדפן אינו רואה אותם. אנו כותבים כללי גישה לנתונים, ולא "סומכים על כל מה שהגיע מהפרונטאנד".
עומס: האם המערכת תעמוד בשיאים ובגידול התוכן?
תוכן סטטי ודפים שמשתנים לעיתים רחוקות מוגשים מהמטמון, ולמקור פונים רק עבור נתונים טריים — עם גידול בתעבורה זה מסיר את עיקר הבקשות. שאילתות כבדות נסגרות עם אינדקסים והגבלת שדות בתגובה. אם התוכן יגדל פי כמה, צוואר הבקבוק נראה מראש לפי מדדים, ולא לפי תלונות משתמשים.
מיגרציה: מה יקרה לאתר ולנתונים הנוכחיים?
אנו מעבירים נתונים במנות, עם בדיקת שלמות בכל שלב, ומשאירים את המערכת הישנה פעילה עד למעבר מאושר. את הסכימה אנו מתארים באופן דקלרטיבי — ניתן להעלות אותה בסביבה חדשה בפקודה אחת. נסיגה לאחור אפשרית בכל שלב, כל עוד לא נותק המתאר הקודם.
תמיכה: האם לא נישאר לבד עם מערכת זרה?
אנו מוסרים קונפיגורציות, סכימת נתונים, תיאור תפקידים והרשאות, והוראות לפעולות אופייניות. המהנדסים שלנו נשארים בקשר לצורך ליווי: עדכונים, טיפול בתקריות, ושדרוג מודלים של תוכן. המערכת נשארת ניתנת לניהול, גם אם צוות אחר מוביל את המשימות.
תארו את המשימה שלכם — נחזור עם הערכה ותוכנית לאינטגרציה.
נדון במשימה שלכם ונחזור עם הערכה
כדי שההערכה תהיה עניינית ולא "ממוצע שוק", אנחנו צריכים הקשר על המשימה: איך בנויה המערכת הנוכחית, אילו נתונים היא שומרת ואילו תרחישים הם קריטיים. להלן מה שאנחנו מבררים בשיחה הראשונה ואילו חומרים עוזרים לחשב את היקף העבודה במדויק.
- מטרה וגבולות. מה צריך להשתנות: מדור חדש, אינטגרציה של Directus עם הפרונטאנד, האצת התגובה או מעבר לסכמת נתונים אחרת. אנחנו מגדירים מה נכלל בשלב הראשון ומה נדחה במודע.
- סטאק נוכחי ומצב. אילו פריימוורקים וגרסאות בפרודקשן, היכן מתארחים השירותים, איך בנויה הבנייה והפריסה. אם הפרויקט כבר חי — צריך גישה לריפוזיטורי או תיאור קצר של הארכיטקטורה.
- מודל נתונים ותוכן. אילו ישויות וקשרים קיימים כעת, מי ואיך עורך אותם, אילו שדות הם חובה. זה קובע את סכמת הקולקציות ב-Directus ואת היקף המיגרציה.
- תרחישים ועומס. אילו עמודים נשמרים במטמון, היכן נדרש real-time, כמה משתמשים ובקשות צפויים בשיא. מזה תלוי הבחירה בין יצירה סטטית לעדכון לפי דרישה.
- מגבלות והרשאות. דרישות לתפקידים והרשאות, עבודה עם שירותים חיצוניים, כללי אחסון נתונים אישיים, סביבות לבדיקות ולקבלה.
- לוחות זמנים ועדיפויות. מה נדרש עד תאריך מסוים ומה ניתן לשחרר בחלקים. כך נציע תוכנית שלא חוסמת כיוונים אחרים.
בתגובה תקבלו הערכה לפי שלבים עם עלויות עבודה, טיוטת תוכנית עבודה עם סדר שחרור ורשימת סיכונים שכדאי לסגור לפני ההתחלה. אם הנתונים עדיין מועטים — תארו את המשימה במילים, ואת השאר נברר בהתכתבות או בשיחה.
