הפוסט נכתב על ידי רוני קרן, מנהל מקצועי של כנס DevGeekWeek ומנהל אקדמי של תחום JAVA בג'ון ברייס הדרכה.
ראשית ננסה למקד את המשמעות הפרקטית והטכנולוגית של מושג זה. Full Stack Developer מתאר מפתחים שהינם בעלי יכולת לבנות את כל רכיבי הפיתוח הכלולים במערכת \ מודול \ שירות באופן רוחבי, ולחבר בינהם.
תיאור שכזה נשמע מופרך מיסודו כאשר מדובר במערכות גדולות כגון Enterprise ו-IT, שכן הידע הנדרש בפיתוח מודולים מתקדמים, בעיקר בצד שרת ותשתיות, הינו רחב דיו כדי לספק משרות רבות וקשה לראות כיצד מפתח, אפילו "עילוי", יכול להכיר את הכל ברמה סבירה.
אבל השינויים המתרחשים לאחרונה בהחלט הופכים את הגישה הזו לריאלית. ספק אם תוכל להתממש במלואה במערכות גדולות אך בהחלט תשולב במודולים ספציפיים במערכות כאלו.
שירותי ענן מייתרים את נושא התשתיות וככל שהעננים הופכים יותר ויותר ל-Platform as a Service (PaaS) – השימוש בהם, במקום בשרתי אפליקציות, הופך לאטרקטיבי (גם תחרות, רמת שירות ואמינות גבוהה ומחירים נמוכים מסייעים בכך).
בנוסף, כמות המודולים ה"קטנים" וה"בינוניים" המשמשים כיום בעיקר לפיתוח בסביבת האינטרנט, כאלה שאינם מצריכים פיתוח רחב היקף ויכולים להישען בקלות על תשתיות ושירותים, הולכת וגדלה בקצב מהיר. סביר להניח שהקצב רק ילך ויגבר ככל שיצוצו עוד לקוחות חדשניים (כגון מובייל ו- IoT) וככל שפלטפורמות השרת ידרשו להשתפר ולספק כל דרישה חדשה שתעלה. בעזרת הכלים הקיימים כיום, מפתח בודד בהחלט יכול ליצר מודול Web מקצה לקצה, ואפילו די במהירות.
לפני שנחקור את השינויים המהווים את המצע ל-Full Stack Web Development ונפרט את הטכנולוגיות והפלטפורמות הרלוונטיות ביותר, נסכם שהמקצוע אינו מופרך כלל ועיקר – להיפך, נכון לו עתיד גדול שנשען למעשה על שתי תופעות עיקריות:
1. זמינותם של שירותים וכלים לפיתוח מהיר וקל הן בצד הלקוח והן בצד השרת.
2. ריבוי של מודולים "קטנים" יחסית, בעיקר לטובת עולם האינטרנט ההולך ומתרחב.
הבה נצלול אל נבכי תופעות אלו ונרד לעומקן.
"זמינותם של שירותים וכלים לפיתוח מהיר וקל הן בצד הלקוח והן בצד השרת"
מהם אותם שינויים המתרחשים בימים אלו? ובכן הנה רשימה חלקית של ה"פרות הקדושות" אשר נשחטו לאחרונה וגם של ה"עיזים" אשר הגיחו לעולם מהדלת האחורית:
א. השגת ביצועים גבוהים ע"י שימוש ב-Clustered Domains? כנראה שכבר לא.
היום Cloud Computing מספק עבורנו יכולות משוכללות הרבה יותר בכל הקשור לזמינות, אבטחה, Parallel Programming, אלסטיות ואינטגרציה. אנא הוסיפו למשוואה את מרכיב התמחור – כשהדומיין מוקם על ידי הארגון כל העלויות חלות עליו ללא קשר במידת השימוש בתשתיות אלו בפועל. למשל ארגון המעוניין לעמוד בעומסי הצרכנים בעת Black-Friday יאלץ לרכוש את כל החומרה והזיכרון הדרושים ליום זה – למרות שמדובר ביום אחד בשנה… ביתר הימים העומסים אפילו לא מתקרבים לכמויות השיא, וניתן לקבוע שבמרבית הזמן לא מתקבלת תפוקה מקסימלית… ועדיין עולה הרבה כסף…
ב. עבודה עם Relational DBs? לא בהכרח, ישנו מעבר ל-NoSQL.
כמויות המידע והאופי שלו אינן מאפשרות לדבוק באופן העבודה המסורתי בכל הקשור לאחסון מידע. אם בעבר רוב רובו של ה-Data היה Structured (וזאת מכיוון שהמערכות שנבנו הגבילו את צורת המידע ואילצו את המשתמשים לפעול בהתאם), כיום המשתמש הינו יצרן מידע בעצמו והוא לא יסכים ש"מישהו" יפרמט את המידע או יאלץ אותו להיכנס לתבניות. מאז עידן Web 2 הגולשים הם אלו שתורמים את רוב המידע הקיים ברשת. פוסטים, Tags, וידאו, תמונות וקול… טבלאות? הצחקתם אותם. NoSQL הינו שם כולל לסוגים שונים של מסדי נתונים אשר שומרים את המידע בקבצים (ולא בטבלאות שנשמרות בקבצים כמו Relational DBs). לפיכך, נושא האחסון הפך להיות ברור וקל יותר לשימוש עבור מפתחי OOP. אצלם למעשה כל נושא ה-SQL לא באמת "התיישב" עם מבני הנתונים האובייקטליים איתם הם רגילים לעבוד (כיצד מבצעים Polymorphism בטבלאות?). עכשיו ישנם פתרונות המאפשרים לדלג על ההמרה ל-,SQL שלא תמיד באמת עושה חסד עם מבני הנתונים המגיעים מתוכנות OO, ואפילו לשפר ביצועים כתוצאה מכך. מדוע להפוך אובייקט ל-SQL INSERT Statement אם ניתן לשמור את האובייקט כפי שהוא בקבצים?
ג. שימוש ישיר ב-HTTP לטובת אינטגרציה
נכון שאנחנו עושים את זה, ואפילו די טוב מאז הגיח XML לאוויר העולם, וזה קרה לפני למעלה מעשור. אבל בכל זאת, כיום לאחר שנים של עבודה עם XML, חלחלה לתודעה העובדה המצערת שאמנם הרעיון באינטגרציה באמצעות self descriptive text הוא לא פחות ממצויין לעולם הפיתוח באינטרנט אבל XML היא כנראה לא הצורה האופטימלית לישם אותו. XML מצריך הפעלת Parsers מאוד לא יעילים בצד השרת ולעיתים גם בצד הלקוח. כמו כן, כולם יסכימו ש-XML אינו האמצעי ה"רזה" ביותר בעולם…אולי להיפך… אנחנו "מבזבזים" המון Characters על שמות תגים ועל התגים עצמם. המידע הגולמי ב-XML עלול להוות אחוזים בודדים ביחס לתגים שעוטפים אותו. בעידן של Big-Data הרצון הוא לשפר את זמני התגובה ולצמצם את כמות התעבורה. שניהם עולים כסף. XML מסתבר "דואג" לשניהם: זמן תגובה ארוך יחסית והמון כסף שמתבזבז על רוחב פס….מהי האלטרנטיבה? פשוט מאוד – JSON. כבר נתמך היטב ונחשב לידע בסיסי, לאו דווקא בקרב מפתחי Jscript.
ד. Jscript מתפשטת
ידוע לכל שיכולותיה של Jscript בצד הלקוח הרחיקו לכת. כיום ניתן לייצר Views מושלם, ואפילו טוב יותר ממסכי Desktop, בדפדפנים. ישנן אינספור ספריות על טהרת ה-Jscript המתרכזות בהצגה דינמיות, responsive UI, חיבור סינכרוני וא-סינכרוני עם מודולים בשרת (מתבסס על AJAX), רכיבי UI מורכבים כגון גרפים ועוד. הכל מאוד "מבושל" ומתוחזק, משתפר ומתקדם בקצב מהיר ביותר (Angular.JS 2…). אבל גם זה מתרחש כבר שנים ולא מהיום… אז מה קרה? מה בכל זאת השתנה כאן? ובכן, בשנים האחרונות Jscript "נעה" לכיוון השרת. כיום ניתן לייצר מודולי Web קטנים ונחמדים (העובדים עם Relational DB וגם עם NoSQL DB על ענן או בדומיין פנים ארגוני) ב-Jscript. טכנולוגיות כמו Node.js ו-Backbone.js בהחלט מאפשרות זאת. אמנם Jscript בצד שרת צריכה עדיין להשתפר ולהתייצב – אבל אם תבדקו כמה מאמצים ופעילויות נעשים בכיוון זה תווכחו לדעת שזה עניין של זמן, ולא הרבה זמן… ליתר ה-Server-side scripting frameworks כמו Ruby-on-Rails יש סיבה להתחיל לדאוג – הגיע שחקן חדש לקבוצה והוא מאוד מאוד פופולארי. נגזרת משמעותית מאוד של עובדה זו היא שמפתחי Jscript המתמחים באופן מסורתי ב-client, יכולים פתאום לייצר גם מודולים שיענו ל-client שבנו מצד ה-Server – ואפילו באותה שפה.
"ריבוי של מודולים 'קטנים' יחסית, בעיקר לטובת עולם האינטרנט ההולך ומתרחב"
עולם האינטרנט אכן הולך ומתרחב – אך לא רק בכמויות המידע ובכמות הלקוחות אלא גם במגוון שלהם. כיום דפדפן נחשב ללקוח הותיק ביותר. בעשור האחרון התחזק מאוד כל נושא המובייל והוא עדיין נושם ובועט. שני סוגי לקוחות אלו מתאפיינים בכך שהם:
א. מצריכים השקעה משמעותית ביותר ב-UI, UX.
ב. מאפשרים לחשוף לוגיקה עסקית מורכבת ביותר (למשל אתר של בנק או אתרי קניות מקוונות).
בשנים האחרונות, עם מבט חזק קדימה, אנו עומדים להיחשף לעידן חדש ומרתק של לקוחות אינטרנט. כיום הוא נקרא IoT (Internet of Things) – הגדרה די כללית וערטילאית. אם נתמקד במילה "things" נמצא שמדובר בכרטיסים חכמים, ננו-טכנולוגיה, סנסורים, Chips ואפילו רקמות חיות (בשנת 2009 הצליחו לייצר תקשורת בין מוח למוח באמצעות האינטרנט – BCI – Brain Communication Interface). כאשר עוסקים בלקוחות אלה הפוקוס הינו בדר"כ עיבוד מידע ולא הצגתו. עובדה זו לבדה די בה כדי לקצר את משך הפיתוח בצד לקוח באופן משמעותי. הוסיפו לה את העובדה שה-Business logic מאוד ממוקד ולא מורכב עבור לקוחות אלה והנה כבר ניתן לדמיין כיצד מפתח יחיד יבצע את המשימה במלואה!
מפתחים בעלי ידע בעולם השרתים יכולים כיום להשיל מעצמם הרבה מאוד עבודה ע"י שימוש בתשתיות קיימות (בעיקר עננים) הן למיחשוב והן לאחסון, ולהתפנות לבניית הלקוחות שלהם.
מפתחים בעולם הלקוח יכולים לבצע את השידרוג הקטן יחסית ולעלות עם Jscript לשרת. ידע בטכנולוגיות CGI אחרות (PHP, Python ועוד) בהחלט לא יזיק. וכך לבנות את המודולים אשר "עונים" ללקוחות שבנו. חשוב לציין שהעננים "מתכוננים" לנדידה זו וכבר כיום מספקים יכולות מדהימות בפיתוח Jscript בענן.
למרבית המודולים האינטרנטיים המודרניים ניתן יהיה להקצות מספר מצומצם של מפתחים אשר יקימו את הכל .End-to-End מפתחים כאלה יחסכו לארגון הרבה מאוד זמן וכסף בחיבור בין מודולים, תקשורת ואינטגרציה של המודולים בשרת עם אלה שבצד הלקוח כיוון שהם יהיו היחידים שמעורבים בפיתוח, ללא צורך בגורמים אחרים. זמן התגובה המהיר לשינויים בלתי פוסקים הינו לחם חוקן של החברות המספקות שירותים באינטרנט. לכן אין פלא שחברות מחפשות Full Stack Developers ודי מתבקש שרובן למעשה מכוונות ל-Full Stack Web Dev.
קרדיט תמונה: developer via shutterstock