Habr יומני מפתחים חזיתיים: ריפקטור ושיקוף

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

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

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

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

בואו נקבע את המשימה

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

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

ממשק Mobile Habr לפני עיבוד מחדש

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

סכימת SSR-CSR ישנה. הרשאה אפשרית רק בשלבים C3 ו-C4, כאשר Node JS אינו עסוק ביצירת HTML ויכול בקשות פרוקסי ל-API.

הארכיטקטורה שלנו של אותה תקופה תוארה בצורה מדויקת מאוד על ידי אחד ממשתמשי Habr:

הגרסה לנייד היא חרא. אני מספר את זה כמו שזה. שילוב נורא של SSR ו-CSR.

היינו חייבים להודות בזה, לא משנה כמה זה היה עצוב.

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

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

בואו נעשה שימוש חוזר בנתונים

בתיאוריה, עיבוד בצד השרת נועד לפתור שתי בעיות: לא לסבול ממגבלות של מנועי החיפוש מבחינת אינדקס SPA ולשפר את המדד FMP (בהכרח מחמיר TTI). בתרחיש קלאסי שסוף סוף גובש ב-Airbnb ב-2013 שנה (עדיין ב-Backbone.js), SSR הוא אותו יישום JS איזומורפי הפועל בסביבת ה-Node. השרת פשוט שולח את הפריסה שנוצרה כתגובה לבקשה. לאחר מכן מתרחשת rehydration בצד הלקוח, ואז הכל עובד ללא טעינות מחדש של הדפים. עבור Habr, כמו עבור משאבים רבים אחרים עם תוכן טקסט, עיבוד שרתים הוא מרכיב קריטי בבניית יחסים ידידותיים עם מנועי חיפוש.

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

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

אחת הבעיות שנוצרו היא חוסר היכולת להמיר מבנים מחזוריים ל-JSON (התייחסות מעגלית); נפתרה פשוט על ידי החלפת מבנים כאלה בעמיתיהם השטוחים.

בנוסף, כאשר עוסקים בתוכן UGC, יש לזכור שיש להמיר את הנתונים לישויות HTML כדי לא לשבור את ה-HTML. למטרות אלו אנו משתמשים he.

צמצום שרטוטים מחדש

כפי שניתן לראות מהתרשים שלמעלה, במקרה שלנו, מופע אחד של Node JS מבצע שתי פונקציות: SSR ו-"proxy" ב-API, שבו מתרחשת הרשאת משתמש. נסיבות אלה לא מאפשרות הרשאה בזמן שקוד ה-JS פועל בשרת, מכיוון שהצומת הוא חוט יחיד, ופונקציית SSR היא סינכרונית. כלומר, השרת פשוט לא יכול לשלוח בקשות לעצמו בזמן שה-callstack עסוק במשהו. התברר שעדכנו את המצב, אבל הממשק לא הפסיק להתעוות, מאחר והנתונים על הלקוח היו צריכים להתעדכן תוך התחשבות בסשן המשתמש. היינו צריכים ללמד את האפליקציה שלנו לשים את הנתונים הנכונים במצב ההתחלתי, תוך התחשבות בכניסה של המשתמש.

היו רק שני פתרונות לבעיה:

• צירוף נתוני הרשאה לבקשות חוצות שרתים;
• לפצל שכבות Node JS לשני מופעים נפרדים.

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

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

בעקבות ההיגיון הזה והרצון שלי לפתור את הבעיה במהירות, בחרתי במשתנים גלובליים. וכפי שקורה לעתים קרובות, אתה צריך לשלם עבורם במוקדם או במאוחר. שילמנו כמעט מיד: עבדנו בסוף השבוע, ביררנו את ההשלכות, כתבנו אַחֲרֵי מַוֵת והתחיל לחלק את השרת לשני חלקים. השגיאה הייתה מאוד מטופשת, והבאג שהיה מעורב בה לא היה קל לשחזר. וכן, חבל על זה, אבל כך או כך, מועד וגונח, ה-PoC שלי עם משתנים גלובליים בכל זאת נכנס לייצור ועובד די בהצלחה בזמן ההמתנה למעבר לארכיטקטורת "שני צמתים" חדשה. זה היה צעד חשוב, כי באופן פורמלי המטרה הושגה - SSR למדה להעביר דף מוכן לחלוטין לשימוש, והממשק UI נעשה הרבה יותר רגוע.

ממשק Mobile Habr לאחר השלב הראשון של refactoring

בסופו של דבר, ארכיטקטורת SSR-CSR של גרסת הנייד מובילה לתמונה זו:

מעגל SSR-CSR "שני צמתים". ה-API של Node JS מוכן תמיד ל-I/O אסינכרוני ואינו נחסם על ידי פונקציית SSR, מכיוון שזו האחרונה ממוקמת במופע נפרד. אין צורך בשרשרת שאילתות מס' 3.

ביטול בקשות כפולות

לאחר ביצוע המניפולציות, העיבוד הראשוני של הדף לא עורר עוד אפילפסיה. אבל השימוש הנוסף ב-Habr במצב SPA עדיין גרם לבלבול.

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

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

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

ArticlesList: [
  { Article1 },
  ...
],
PageArticle: { ArticleFull1 },

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

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

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

ArticlesList: {
  ROUTE_FEED: [ 
    { Article1 },
    ...
  ],
  ROUTE_ALL: [ 
    { Article2 },
    ...
  ],
}

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

ArticlesIds: {
  ROUTE_FEED: [ '1', ... ],
  ROUTE_ALL: [ '1', '2', ... ],
},
ArticlesList: {
  '1': { Article1 }, 
  '2': { Article2 },
  ...
}

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

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

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

הופך את ההורדה למהנה יותר

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

הברלאודינג

משקף

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

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

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

מקור: www.habr.com