ריבוי דיירים בפלטפורמת אופן סורס - למה בכלל?

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

בעיית זיכרון לשרתים ״חלשים״

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

בעיית התחרות

אומנם הפלטפורמה הזו מתחרה בקונספטים של וורדפרס בלבד, כלומר - קוד פתוח שמציע בנקודת ההתחלה את כל השירותים, כאשר כל אחד מהם ניתן לביטול , החלפה, או שינוי בהתאם לצורך, אבל עדיין - התחרות בשוק המערכת המתקדמות של ימינו נע סביב הבאזז-וורד הנהדר JAMstack.
כל הפלטפורמות שמשתתפות ביקום הריבה, מספקות לרוב חלק אחד או יותר מתוך סך החלקים והכלים ש״צריך״ כדי להרים אתר תוכן, וכל אחד ״מומחית״ בתחומה. שילוב של מספר כלים ביחד יביא להקמתו של אתר תוכן.
החיסרון הכי בולט כרגע בקונספט - הוא לא מתאים לאנשים לא טכנולוגיים.
נקודת המוצא שלי עם Greenpress היא קודם כל ההתאמה לאנשים לא טכנולוגיים, כאלו שרוצים שהאתר פשוט יעבוד, ויספק פיצ׳רים קלים לתפעול וממשק ניהול נוח, לפחות כמו של וורדפרס, שכולל את כל נושא ה-seo, תכנים, משתמשים, ועוד.
לשם אני חותר. אבל - אי אפשר להתעלם מהעובדה שיש עדיין משתמשים שהיו רוצים לקבל JA, או JA++ מתוך סך ה-JAMstack, אויל אפילו JA ועוד m קטנה.

הפתרון לזיכרון - בעיקר עבודת נמלים

אני לא ארחיב כאן על איך למצוא בעיות זיכרון ב-NODE, כי זה נושא ארוך (האמת שאני אפילו לא יודע איך להתחיל מאמר כזה, כי גם כשאני חיפשתי מאמרים טובים בעניין, הגעתי למאמרים שדי גימגמו את התשובה ״תתחיל לחפש״), אבל אולי בעתיד אכתוב על זה, אבל בינתיים - שמתי לעצמי רף להגיע לצריכת זיכרון שמספיקה לעבודה גם בשרתים זולים עד זולים מאוד, כאלו שמריצים עליהם חבילות אחסון משותף.
נקודת המוצא הראשונה היתה לעבור על כל הסרביסים, לתקן בעיות של זליגה. על-הדרך, כבר רציתי לשפר את חווית השימשו והמהירות, וגם להזיז שימוש בזיכרון למקום הראוי לו - והוספתי שימוש ב-Redis לצורך כך, מה שהוסיף לי את התחושה שאני לא מבזבז את זמני על ריפקטור, וגם משקיע בשיפורי חוויה בנוסף. :)
לאחר מכן עברתי לחפש זליגות זיכרון ב-Nuxt.js. מסתבר שיש לא מעט, והרבה דרכים להגיע למצבים של זליגה (למותר לציין, אני מדבר על זליגה שמתקיימת בצד השרת של הרינדור, ולא בצד הקליינט).
ככלל אצבע, הייתי ממליץ לבחון כל נקודה שבה יש ניהול store באפליקציה. אלו הנקודות הראשונות להתנפח, שהפריימוורק לא מצליח להתמודד עם הסיטואציות של ניקוי הזיכרון בשרת לאחר הרינדור עובר קליינט מסויים.
העבודה הזו הניבה פירות, וניצול הזיכרון ירד באופן דרסטי.

אז איך מגיעים לריבוי דיירים?

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

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