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

1. אפליקציית SPA בצד לקוח, Micro Services או Serverless בצד השרת

מה שהולך היום ברוב היישומים החדשים לפחות בשלב בניית ה MVP הוא פריימוורק כלשהו בצד הלקוח (React, Vue, Angular) ופונקציות "ללא שרת" בצד השרת.

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

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

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

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

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

2. אפליקציית SPA בצד לקוח, REST API או GraphQL בצד השרת

אפשרות שניה עדיין פופולרית היא להשתמש ב Node.JS או Flask בצד השרת כדי לבנות API יחסית קטן ובצד הלקוח להישאר עם ה React, Vue או Angular. הפעם השרת רץ על מכונה שלנו ואנחנו האחראיים הבלעדיים לכתיבתו ולכן יש יותר סיכוי שנהיה זהירים ונכתוב קוד יעיל ומאובטח יותר מאשר בארכיטקטורת Serverless.

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

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

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

3. דפי אינטרנט אינטרקטיביים בצד הלקוח, פריימוורק בצד השרת

אפשרות שלישית שכבר הרבה פחות אופנתית היום היא להשתמש בפריימוורק צד-לקוח רק למסכים המורכבים ביישום, אבל לוותר על ה SPA ולהשתמש בפריימוורק בצד השרת (למשל JSP, Rails, Laravel או Node.JS עם EJS).

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

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

4. דפי אינטרנט משעממים בצד הלקוח (jQuery), פריימוורק בצד השרת

אפשרות רביעית וממש לא פופולרית היום היא שימוש בדפי אינטרנט רגילים ומקסימום בספריה כמו jQuery בצד הלקוח, ובפריימוורק כלשהו בצד השרת (למשל Laravel, Rails, JSP או Node.JS עם EJS).

היתרון הגדול כאן הוא בגיזרת העלות - יש עדיין המון מתכנתים בארץ ובעולם שיודעים טוב PHP ו jQuery אבל לא מכירים מספיק טוב ריאקט או אנגולר. מתכנתים אלה לא מצליחים למצוא עבודות בחברות שמפתחות בסטאקים היותר מורכבים ולכן הם מוכנים לעבוד במחירים נמוכים יותר. בשביל להוזיל עלויות עוד יותר אפשר להוציא חלק ניכר מהעבודה לחו"ל.

החיסכון בעלויות אומר שאפשרות זו מתאימה ליזמים קטנים או לצוותי פיתוח קטנים שמתכננים לבנות מערכת בתור Bootstrap. מהירות הפיתוח שלכם תהיה מספיק טובה כדי להתחרות (מבחינת פיצ'רים) בחברות הגדולות יותר. אומנם לא יהיו לכם את כל הרעש והצלצולים של הסטארט-אפים שבונים Single Page Apps אבל כן תוכלו לתת פיתרון טוב ללקוחות שמוכנים להתפשר על חווית משתמש בשביל פיצ'ר ספציפי או יחס אישי.

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