בניית אתרים מורכבים: מתי וורדפרס כבר לא מספיק

רוב האתרים בעולם נבנים היטב על מערכות תבניתיות, וזה בסדר גמור. אבל יש נקודה שבה האתר מפסיק להיות אתר ומתחיל להיות אפליקציה: משתמשים מחוברים, נתונים שמשתנים, לוגיקה עסקית וחיבורים למערכות אחרות. מהרגע הזה, כל תוסף נוסף לא פותר את הבעיה אלא מוסיף לה שכבה. המדריך הזה מסביר איך מזהים את הנקודה הזו ומה עושים כשמגיעים אליה.

מה הופך אתר למורכב

מורכבות אינה נמדדת במספר העמודים או ביופי העיצוב. היא נמדדת בכמות העבודה שהאתר מבצע. אלה הסימנים המובהקים:

• משתמשים מחוברים עם הרשאות. ברגע שיש התחברות, ובעיקר כשיש כמה סוגי משתמשים שרואים דברים שונים, נכנסים לעולם אחר לגמרי.
• נתונים שנוצרים ומשתנים. האתר לא רק מציג תוכן שהוזן מראש, אלא שומר מידע שהמשתמשים מייצרים ומשנים.
• לוגיקה עסקית. חישובי מחיר, זכאות, הנחות, תהליכי אישור. כל חוק עסקי הוא קוד שצריך לכתוב, לבדוק ולתחזק.
• חיבור למערכות חיצוניות. סליקה, מלאי, הנהלת חשבונות, שילוח, מערכת ניהול פנימית.
• נפח או ביצועים. עשרות אלפי פריטים, אלפי משתמשים במקביל, או חיפוש שצריך לרוץ על כמות נתונים גדולה.
• דרישות רגולציה. נגישות, פרטיות, שמירת תיעוד, בקרת גישה.

7 סימנים שהמערכת הנוכחית נשברת

1. יש יותר משלושים תוספים פעילים, ואף אחד לא זוכר מה חצי מהם עושים.
2. כל עדכון מפחיד. הצוות דוחה עדכוני גרסה מחשש שמשהו יישבר, ואז נוצר פער אבטחה.
3. האתר איטי ואף אחד לא יודע למה. התקינו תוסף מטמון, זה עזר קצת, וזהו.
4. דרישה עסקית פשוטה נענית ב"אי אפשר". זה הסימן החד ביותר: המערכת החלה להכתיב לעסק מה מותר לו.
5. מייצאים לאקסל כדי לעשות משהו בסיסי, כי המערכת לא יודעת להציג את החתך הנדרש.
6. תוספים מתנגשים זה בזה. מתקנים דבר אחד ונשבר אחר.
7. עלות התוספים בתשלום הצטברה לסכום חודשי משמעותי, ועדיין לא מקבלים בדיוק את מה שצריך.

שניים או שלושה מהסימנים האלה עדיין ניתנים לתיקון בתוך המערכת הקיימת. חמישה ומעלה, ובדרך כלל תשלמו על תחזוקה יותר משהייתם משלמים על בנייה נכונה.

איך בנוי אתר מורכב מבפנים

ההבדל המהותי הוא הפרדה בין שכבות. באתר תבניתי הכול שזור יחד, ולכן שינוי בעיצוב עלול לשבור לוגיקה. באתר מורכב הבנוי נכון:

• שכבת התצוגה אחראית רק על מה שהמשתמש רואה. אפשר לשנות אותה לגמרי בלי לגעת בלוגיקה.
• שכבת הלוגיקה מחזיקה את החוקים העסקיים במקום אחד מוגדר, כך שכלל שמשתנה מתעדכן בנקודה אחת ולא בעשרה מקומות.
• שכבת הנתונים מתוכננת מראש לפי מה שהמערכת באמת צריכה, כולל אינדוקס נכון שמאפשר שאילתות מהירות גם כשהטבלה גדלה.
• שכבת API מאפשרת לאותה מערכת לשרת בעתיד גם אפליקציית מובייל או פורטל נוסף בלי לבנות הכול מחדש.

ההשקעה בהפרדה הזו נראית מיותרת בחודש הראשון ומשתלמת מהחודש השישי. הרחבה על העיקרון הזה נמצאת במדריך פיתוח מערכות Web לעסקים.

ביצועים בקנה מידה גדול

אתר עם מאה מוצרים ואתר עם חמישים אלף מוצרים הם שתי בעיות הנדסיות שונות לחלוטין. מה שמחזיק ביצועים כשהנתונים גדלים:

• שאילתות מתוכננות ואינדוקס נכון. זו הסיבה הנפוצה ביותר לאיטיות באתרים גדולים, והיא כמעט תמיד ניתנת לפתרון.
• מטמון בשכבות. תוצאות שחוזרות על עצמן נשמרות זמנית במקום להיות מחושבות מחדש בכל בקשה.
• רשת הפצת תוכן. קבצים סטטיים ותמונות מוגשים משרת קרוב פיזית לגולש.
• עיבוד מחוץ לבקשה. משימות כבדות כמו הפקת דוח או שליחת אלפי מיילים רצות ברקע ולא מעכבות את המשתמש.
• חיפוש ייעודי. מנוע חיפוש אמיתי במקום שאילתת טקסט על בסיס הנתונים, כשהתוכן גדול.
• טעינה מדורגת של תמונות וקוד שנטען רק כשצריך אותו.

אזורים אישיים והרשאות

זהו החלק שהכי מרבים לזלזל בו, והוא מקור עיקרי לתקלות אבטחה. עקרונות שחייבים להתקיים:

• בדיקת הרשאה בצד השרת, תמיד. הסתרת כפתור בממשק אינה אבטחה. אם השרת לא בודק מי מבקש, המידע חשוף לכל מי שיודע לנחש כתובת.
• הרשאה מינימלית כברירת מחדל. משתמש חדש מקבל את המינימום, ומרחיבים ביודעין.
• הפרדה בין בעלות לצפייה. משתמש רשאי לראות רק את הנתונים שלו, גם אם יחליף מספר מזהה בכתובת.
• ניהול הפעלות תקין. ניתוק אוטומטי, אפשרות לסיים הפעלות בכל המכשירים, והגנה מפני חטיפת הפעלה.
• תיעוד פעולות רגישות, כדי שאפשר יהיה לחקור בדיעבד מה קרה.

אינטגרציות וזרימת נתונים

באתר מורכב, האתר הוא בדרך כלל רק נקודה אחת בזרימת מידע רחבה יותר. שאלות שצריך לענות עליהן באפיון ולא בפיתוח:

• מה מקור האמת לכל סוג נתון. אם המלאי מנוהל גם באתר וגם במערכת הפנימית, מי מנצח כשיש סתירה.
• האם הסנכרון בזמן אמת או מתוזמן. זמן אמת מדויק יותר אך יקר ושברירי יותר.
• מה קורה כשמערכת בצד השני לא זמינה. פעולות צריכות להיכנס לתור ולהתבצע כשהחיבור חוזר, ולא להיעלם.
• איך יודעים שחיבור נשבר. בלי ניטור והתראה, מגלים מהלקוח.

אבטחה ועמידות

ככל שהאתר מחזיק יותר נתונים ומבצע יותר פעולות, כך הוא מטרה משמעותית יותר. הבסיס שחייב להתקיים: הצפנת תעבורה ונתונים רגישים, הגנה מפני החולשות הנפוצות המוכרות בתעשייה, הגבלת קצב בקשות כדי למנוע ניצול לרעה, גיבויים אוטומטיים עם בדיקת שחזור תקופתית, ותהליך מסודר לעדכוני אבטחה של ספריות צד שלישי.

נקודה שרבים מפספסים: עמידות אינה רק אבטחה. מערכת טובה יודעת להתנהג בהיגיון גם כשמשהו נכשל, למשל להציג הודעה ברורה ולשמור את מה שהמשתמש הזין, במקום להציג מסך שגיאה ולאבד את העבודה שלו.

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

העצה המעשית ביותר: אל תשיקו הכול בבת אחת. בונים את הליבה שפותרת את הכאב המרכזי, מעלים לאוויר, מודדים איך משתמשים בה בפועל, ומרחיבים לפי נתונים. פרויקטים שמנסים להשיק עשרה מודולים ביום אחד הם אלה שחורגים בתקציב ובזמן.

שאלות נפוצות