?איך לעזאזל אפשר להחליט באיזה תשתית ווב לפיתוח כדאי לבחור

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

בשנים האחרונות, מגמת השימוש בתשתיות פיתוח ווב (javascript framework) לבניית אפליקציות דף-יחיד (SPA) בווב, מתעצמת והולכת. כמות התשתיות הזמינות וקצב ההתפתחות שלהם, שובר שיאים חדשים, הרשת מפוצצת בפוסטים נלהבים שנכתבים ע”י מעריצים פנאטים של תשתית זו או אחרת, בהתחשב במצב, לא פלא שהתשובה לשאלה “מה תשתית הפיתוח הבאה לווב שכדאי ללמוד?”, לא ברורה באופן חד משמעי, הפוסט לא מתיימר לתת תשובה חד משמעית לשאלה, אלה להציג את סך הקריטריונים שהגדרנו כתנאי לבחירה בתשתית הווב בחברת Arrakis.

גם אנחנו ב Arrakis, מתחבטים ממש בימים אלו בשאלה מה תהיה תשתית הפיתוח לווב שתלווה אותנו בשנים הבאות, עיקר עיסוקנו ב Arrakis הוא במערכות client server, כאשר צד השרת ממומש בJAVAEE, וה client ברוב המקרים הוא אפליקציית WEB, לכן האוריינטציה של הקריטריונים מוכוונת לסוג המערכות שמעניינות אותנו בArrakis, למשל אין כמעט התייחסות לפיתוח במובייל. בסופו של התהליך, מטרתנו להקים תשתית פיתוח פרוייקטי frontend שתשמש תבנית ובסיס לפרוייקטי פיתוח עתידיים בחברה.

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

דרישות סף טכנולוגיות מהתשתית:
– מודולריות – pluggble design: מאחר וברוב פרוייקטי מערכות שרת לקוח ישנם מודולים משותפים, (לדוגמא מודול הזדהות וניהול משתמשים), הרעיון הוא לבנות תבנית פיתוח שמורכבת מאוסף פלאגינים, שאותם ניתן לחבר או לנתק מהפרוייקט בקלות, בהתאם לדרישות ספציפיות.
– פשטות אינטגרציה עם קומפוננטות חיצוניות– האינטגרציה עם העולם האינסופי של ספריות javascript בתחומים קומפוננטות UI, מיפוי (כמו leaflet), ויזואליזציה (כמו d3), ועוד.
– פשטות לימוד, התקנה, ותפעול סביבה ראשונית – הדרישה היא שתהליך בניית סביבת הפיתוח הראשונית יהיה פשוט יציב וקל, ויקח לא יותר מכמה דקות, גם למפתחים צעירים, תוך שימוש במנהלי החבילות וכלי הבנייה הסטנדרטיים בעולם הווב כמו npm ,grunt ו gulp.
– ביצועים – מניסיוננו בעבר נתקלנו בבעיות ביצועים שקשורות באופן ישיר ליכולת ההתמודדות של תשתיות פיתוח הווב עם הצגת כמות גדולה של נתונים, או יכולת עיבוד\טיפול בכמות גדולה של אירועים בו זמנית.
– טסטביליות – לתשתית חייבת להיות אינטגרציה מלאה ומובנית עם תשתיות בדיקה בעולם הווב, זה כולל את בדיקות היחידה – karma ו jasmine, ובדיקות קצה לקצה עם selenium.
– פשטות אריזה (bundling) והתקנה, גודל תשתית – יכולת מובנית לארוז את כל התוצרים הנדרשים להתקנה בצורה אלגנטית, מינימליסטית ופשוטה בקליק אחד. הגודל הסופי של תיקיות התוצרים חייב להיות מינימלי.
– Binding בין המודל ל VIEW ולהיפך – מרכיב מרכזי והכרחי בכל תשתיות הפיתוח המודרניות בעולם הווב, בהקשר הזה הדרישה היא שהשימוש ביכולת בתשתית יהיה פשוט ואלגנטי.
– ניווט (Routing) – בין הדפים השונים באפליקציה, יכולת לשלוט ולהגדיר בצורה פשוטה, איך ומאיפה ניגשים לכל חלק באפליקציה, מה רמת ההרשאה הנדרשת כדי לגשת לדף, והאם יש צורך בהזדהות כדי לגשת לאותו חלק במערכת.
– לוקליזציה – Localization – תמיכה מובנית במנגנון לוקליזציה הכולל קבצי מילון לרבות תמיכה בשפות הנכתבות מימין לשמאל.

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

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

Leave a Reply

Your email address will not be published. Required fields are marked *