השרת המושלם לכתיבת אפליקציות צד-לקוח

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

shutterstock java code

מאת גיל תייר, ארכיטקט.

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

דמיינו לכם את דורית, מגיעה לעבודה בתחילת היום. היא נלהבת במיוחד היום כי זהו היום בו היא מתחילה לכתוב את צד הלקוח של אפליקציה חדשה. היא הייתה רוצה להתיישב על המקלדת, ולהתחיל להשתמש בכל אותן טכנולוגיית נפלאות שקראה עליהן בגיקטיים – טכנולוגיות כגון React, ES6, מודולים של JavaScript, ו-LESS. בעולם מושלם היא הייתה פותחת את ה-editor החביב עליה וכותבת  את ה-HTML, ה-CSS, וה-JavaScript של האפליקציה.

אך היא אינה חיה בעולם מושלם. היא מגלה שכדי לעבוד ב-React היא צריכה לקמפל את קוד ה-React המיוחד (JSX) ל-JavaScript רגיל. ואם ברצונה לעבוד עם ES6, הגרסה החדשה של JavaScript שעדיין אינה נתמכת באופן מלא בכל הדפדפנים, היא צריכה לקמפל אותה ל-JavaScript רגיל. וכנ״ל ל-LESS, הגרסה המשופרת ל-CSS.

לקמפל? זה לא טבעי לתוכניתנית צד-לקוח שרגילה פשוט להקיש על F5 כדי לראות את השינויים שלה. אבל אין ברירה – דורית השאפתנית מתחילה להתקין את כל הקומפיילרים שהיא צריכה. ובגלל שהיא עצלנית מאוד, היא משתמשת בכלים כמו grunt או gulp כדי לעשות אוטומציה לתהליך הקומפילציה.

מורכבות מקרית

הנה עברו להם יומיים ודורית המסכנה עוד לא התחילה לכתוב שורת קוד אחת. נכון, היא הכינה לעצמה את הכלים שיאפשרו לה לעבוד עם React, ES6 ו-LESS, אבל בעצם היא הייתה עסוקה במה ש-Fred Brooks קרא לו מורכבות מקרית – מורכבות שאינה מהותית לבעיה העומדת בפני התוכניתנית, אלא נובעת מעצם המערכת שבה היא עובדת.

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

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

הפתרון – שינוי ארכיטקטוני

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

ואכן יש לנו שרת כזה – Apache או Nginx. הוא יודע להגיש קבצים סטטיים. אבל האם הוא יוכל לעשות טרנספורמציות על JavaScript או CSS או HTML? לא. בשביל זה היינו רוצים שרת ייעודי, שיתאים לצרכים של תוכניתני צד הלקוח.

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

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

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

כעת, עם פתרון כזה, חייה של דורית יהיו פשוטים יותר – היא תדאג לקוד, ותוכל לכתוב את הקוד כרצונה – עם שימוש ב-ES6, LESS, React ושאר דברים מתקדמים – והשרת הזה ידאג להגשתו, עם כל הכרוך בכך – קומפילציה, מיניפיקציה, ניטור, ושאר שירותים שיכולים וצריכים לקרות בצד השרת. האם נוכל להחליף את קשת הכלים שיש לנו היום – gulp, grunt, webpack, babel וכו׳ – בשרת אחד שיעשה את כל העבודה הזו בצד-שרת? אני חושב שכן, אבל רק הזמן יגיד אם צדקתי.

קרדיט תמונה: computer code via shutterstock

הכתבה בחסות Wix Code Day

Wix Code Day הוא האקתון למפתחי צד-לקוח, במסגרתו יתנסו המפתחים בפלטפורמה החדשה Wix Code, המשפרת משמעותית את פיתוח צד-הלקוח ומאפשרת למפתח להשתמש בטכנולוגיות כמו ES6, LESS, Javascript Modules בצורה שקופה ופשוטה. זו הפעם הראשונה שמפתחים יוכלו לכתוב אפליקציות ולשלב אותם בתוך אתרי ה-Wix שלהם. האירוע יתקיים בביתן 26 בנמל תל אביב, בין התאריכים 26-31 ביולי. פרסים מובטחים לכולם ולזוכים במקומות הראשונים פרסים שווים במיוחד. באירוע יהנו המפתחים מאוכל,שתיה ושלל פינוקים. לפרטים נוספים והרשמה.


כתב אורח

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

הגב

16 תגובות על "השרת המושלם לכתיבת אפליקציות צד-לקוח"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

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

סידור לפי:   חדש | ישן | הכי מדורגים
רוי
Guest

לא מסכים בכלל.
כלים כמו gulp, grunt וכו’ הם חלק בלתי נפרד מעולם ה front-end לכן כל מפתח צד לקוח צריך להכיר אותם לפחות ברמה הבסיסית. כאשר מפת לומד תשתית חדשה כגון React, הוא חייב לקחת בחשבון את המשמעויות של קימפול, מיניפיקציה וכו.
תאר לך מפתח BL שלא יודע לעבוד עם DB או עם API חיצוניים(אני לא הייתי מעסיק אחד כזה).

נדב
Guest

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

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

אריאל
Guest

אם כבר הרמת את הכפפה למה שלא תילבש אותה ושתף אותנו?

יונתן
Guest

רוי – שרת כזה לא אמור לסתור ידע בסיסי ב-grunt או gulp (לדעתי ללמוד את שני הכלים לעומק לא לוקח יותר מיום), הוא אמור לקצר תהליכים עבור המפתח כדי שיהיה FrontEnd ולא DevOps.

זה כמו לומר שלא כדאי להשתמש ב-Webstorm וכדאי רק ב-mate בגלל שאחרת המפתח מנותק מה-terminal ולכן פחות בקיא בקרביים של המערכת.

במילים אחרות – זה קיצור דרך ש(י)ב(ו)א להקל, לא להחליף ידע.

דור
Guest

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

asd
Guest

הכתב מדבר שטויות! כל זב חוטם יודע שאפשר להשתמש ב[הכנס_שם_פלצני_כאן] שזה שירות ממש פשוט שאפשר לכתוב בו את האות K והוא מבין כבר הכל וכותב לך את כל הקוד שלך דרך הטרמינל + מגייס לך כסף ממשקיעים ומנפיק אותך בבורסה!

Gil Tayar
Guest

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

Gil Tayar
Guest

דור – לגמרי נכון. Meteor היא בדיוק פלטפורמה כזאת. אבל היא בנוייה ל-framework אחד בלבד. אני מחפש פלטפורמה שתהיה אגנוסטית לאיזה framework אתה משתמש בו.

ChenReuven
Guest

גיל, למה את מטאור בנויה רק ל- Fw אחד? הרי אפשר לשלב בו כל fw fe שאתה חפץ. כגון: react, Angular, כל fw שנתמך כחבילה במטאור או להשתמש בברירת מחדל שלהם blaze, דווקא מהבחינה הזאת מטאור היא אגנוסטית.

בקשר למה שרשמת בכתבה, נשמע מאוד מעניין, אני חושב שהכיוון הוא גם קינפוג של השרת בצורה של “חבילות” (כמו custom builder כזה), שתסמן לו מה המשימות של השרת והוא יעשה אותם בצורה חכמה עם watch על קבצים, תיקיות, פונקציות ועוד, סוג של server FE pack :)

תודה על הכתבה

נדב
Guest

asd – :D

נדב
Guest

גיל – הפתיע אותי לקרוא שיש מי שכבר משתמש ב-ES6. לא מפריע לך שכמעט ואין תמיכה ברוב הפיצ׳רים באף אחד מהדפדפנים הגדולים להוציא FF? או שזו היתה רק דוגמא בכדי להמחיש בכמה טכנולוגיות שונות צריך מפתח FrontEnd טוב להיות בקיא?

Ran
Guest

לפי מה שהבנתי זה לא משנה שאין תמיכה ב-ES6 כי השרת שלו גם ככה מקמפל את זה ל vanilla javascript. ככה הוא נהנה מסביבת פיתוח עדכנית. רק לא ברור לי איך הוא חוסך את הקימפול במכונה הלוקאלית אלא אם הוא מריץ את הקוד שלו רק על FF . . .

yaky refael
Guest

תרשו לי לתת פה תגובה קצת משונה: לפני כחודשיים כתבתי מאמר באותו נושא, אפילו ממש דומה לכתבה שמוצגת כאן. פניתי אליכם בכדי לתת לקהל הגולשים שלכם גם לקרוא ולהחשף למאמר שכתבתי. תשובתכם הייתה: ” כתבה טובה אבל פחות מתאימה לפרסום אצלנו. קהל הקוראים שלנו מקצועי, נקודת הפתיחה שלו היא משם והלאה “.. אז יש פה משהו מוזר, כי הנושאים הם אותם נושאים ואפילו כתבתי את זה בצורה ידידותית גם לאנשים שלא ממש פרונטאנדים. יש מצב שזה בגלל שהכותב פה הוא ארכיטקט מחברת וויקס? אשמח לתגובה עניינית הפעם. ובלי שום קשר, הכתבה מאוד מעניינת ותודה לכותב ששיתף. http://yaky-refael.com/blog/web-developer-journey/

מישה
Guest

זה כנראה כי אולי WIX שלמו להם כדי יפרסמו את הכתבה

גלעד
Guest

יש משהו כזה, יש לו עוד מה להשתכלל אבל הבסיס קיים.

http://harpjs.com/

שטותר
Guest

לא ברור מה הכותב רוצה.
באשר לחלק האחרון – אז יש כלים כמו מטאור וכן יש כלי שנותן seed של פרויקט ע”פ העדפות: YeoMan – הכלי עובד עם ג’ניירוטרים, למשל gulp+angular+material ושואל כמה שאלות… יש את כל הקומבינציות הפופולאריות: gulp / grunt,less/sass, angular / ember
.. , bootstrap / material, react ועוד.
תוך דקה יש פרויקט מוכן שעושים עליו npm i, bower i ואפשר לעבוד.

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

בהצלחה.

wpDiscuz

תגיות לכתבה: