לכתוב קוד בחושך - חלק שני

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

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

האמירה הזאת שלו גרמה לי להרהר בדבר ואפילו פתחתי דיון עם החברים מהעבודה על זה

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

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

 (ועוד אתגרי פרונטאנד שבואו, אני לא באמת מכיר את כולם)

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

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

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

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

 

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

3. שומר הסף של הדאטה בייס, ולידציות

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

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

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

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

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

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

האנדפוינט שלו תמיד מוכן לכל בקשה ובכל זמן.

 

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

 

זהו לבינתיים

אם נסכם את הפוסט הזה יחד עם הקודם אז…

שרת הבקאנד עוזר לנו, 

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

 

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

אם לא קראתם עדיין את הפוסט הקודם שעסק בין השאר במוטיבציה שלי לכתיבה על בקאנד, ולמה אני מרגיש שאני כותב קוד בחושך, מוזמנים לקרוא על זה ממש כאן - https://www.achiya.dev/blog-post/backend1

זהו להיום חברות וחברים

הלכתי לעסוק בפיתוח הצד המאתגר באמת 😉