Дневници на разработчици от предния край на Habr: рефакторинг и отразяване

Винаги съм се интересувал от това как Habr е структуриран отвътре, как е структуриран работният процес, как са структурирани комуникациите, какви стандарти се използват и как обикновено се пише код тук. За щастие получих такава възможност, защото наскоро станах част от екипа на habra. Използвайки примера за малък рефакторинг на мобилната версия, ще се опитам да отговоря на въпроса: какво е да работиш тук отпред. В програмата: Node, Vue, Vuex и SSR със сос от бележки за личен опит в Habr.

Първото нещо, което трябва да знаете за екипа за разработка е, че сме малко. Недостатъчно - това са три предни, две задни и техническо ръководство на всички Habr - Baxley. Има, разбира се, и тестер, дизайнер, три Вадим, метла чудо, маркетинг специалист и други Bumburums. Но има само шест преки сътрудници на източниците на Habr. Това е доста рядко - проект с многомилионна аудитория, който отвън изглежда като гигантско предприятие, в действителност изглежда по-скоро като уютен стартъп с възможно най-плоската организационна структура.

Подобно на много други ИТ компании, Habr изповядва Agile идеи, CI практики и това е всичко. Но според моите усещания Habr като продукт се развива повече на вълни, отколкото непрекъснато. И така, в продължение на няколко поредни спринта, ние усърдно кодираме нещо, проектираме и преработваме, разбиваме нещо и го поправяме, решаваме тикети и създаваме нови, стъпваме на рейк и се прострелваме в краката, за да пуснем най-накрая функцията в производство. И тогава идва известно затишие, период на преустройство, време да се направи това, което е в квадранта „важно-не спешно“.

Точно за този спринт „извън сезона“ ще стане дума по-долу. Този път включваше рефакторинг на мобилната версия на Habr. Като цяло компанията възлага големи надежди на него и в бъдеще трябва да замени целия зоопарк от превъплъщения на Habr и да се превърне в универсално междуплатформено решение. Някой ден ще има адаптивно оформление, PWA, офлайн режим, потребителско персонализиране и много други интересни неща.

Да поставим задачата

Веднъж, при обикновено изправяне, един от предните говори за проблеми в архитектурата на компонента за коментари на мобилната версия. С оглед на това организирахме микросреща във формат групова психотерапия. Всички се редуваха да казват къде ги боли, записваха всичко на хартия, съчувстваха, разбираха, само дето никой не пляскаше. Резултатът беше списък от 20 проблема, който ясно показа, че мобилният Habr все още има дълъг и трънлив път към успеха.

Бях загрижен предимно за ефективността на ресурсите и това, което се нарича плавен интерфейс. Всеки ден, по маршрута вкъщи-работа-вкъщи, виждах как старият ми телефон отчаяно се опитва да покаже 20 заглавия във емисията. Изглеждаше нещо подобно:

Mobile Habr интерфейс преди рефакторинг

Какво става тук? Накратко, сървърът обслужва HTML страницата на всички по един и същи начин, независимо дали потребителят е влязъл или не. След това клиентският JS се зарежда и отново изисква необходимите данни, но коригирани за авторизация. Тоест реално свършихме една и съща работа два пъти. Интерфейсът трепна и потребителят изтегли стотина допълнителни килобайта. В детайли всичко изглеждаше още по-зловещо.

Стара схема SSR-CSR. Упълномощаването е възможно само на етапи C3 и C4, когато Node JS не е зает с генерирането на HTML и може да прокси заявки към API.

Нашата архитектура от онова време беше много точно описана от един от потребителите на Habr:

Мобилната версия е глупост. Казвам го както е. Ужасна комбинация от SSR и CSR.

Трябваше да го признаем, колкото и тъжно да беше.

Оцених опциите, създадох билет в Jira с описание на ниво „лошо е сега, направете го както трябва“ и разложих задачата на широки щрихи:

• повторно използване на данни,
• минимизирайте броя на преначертанията,
• премахване на дублирани заявки,
• направи процеса на зареждане по-очевиден.

Нека използваме повторно данните

На теория изобразяването от страна на сървъра е предназначено да реши два проблема: да не страда от ограниченията на търсачката по отношение на SPA индексиране и подобряване на показателя FMP (неизбежно влошаване TTI). В класически сценарий, че най-накрая формулиран в Airbnb през 2013 г година (все още на Backbone.js), SSR е същото изоморфно JS приложение, работещо в средата на Node. Сървърът просто изпраща генерираното оформление като отговор на заявката. След това се извършва повторно хидратиране от страна на клиента и след това всичко работи без презареждане на страницата. За Habr, както и за много други ресурси с текстово съдържание, изобразяването на сървъра е критичен елемент в изграждането на приятелски отношения с търсачките.

Въпреки факта, че са изминали повече от шест години от появата на технологията и през това време много вода наистина е изтекла под моста в света на предния край, за много разработчици тази идея все още е забулена в тайна. Не останахме настрана и внедрихме приложение Vue с поддръжка на SSR в производството, като пропуснахме един малък детайл: не изпратихме първоначалното състояние на клиента.

Защо? Няма точен отговор на този въпрос. Или не искаха да увеличат размера на отговора от сървъра, или поради куп други архитектурни проблеми, или просто не се получи. По един или друг начин, изхвърлянето на състоянието и повторното използване на всичко, което е направил сървърът, изглежда доста подходящо и полезно. Задачата всъщност е тривиална - просто се инжектира в контекста на изпълнение и Vue автоматично го добавя към генерираното оформление като глобална променлива: window.__INITIAL_STATE__.

Един от възникналите проблеми е невъзможността за конвертиране на циклични структури в JSON (кръгла справка); беше решен чрез просто заместване на такива структури с техните плоски аналогове.

Освен това, когато работите с UGC съдържание, трябва да запомните, че данните трябва да бъдат преобразувани в HTML обекти, за да не се наруши HTML. За тези цели използваме he.

Минимизиране на преначертанията

Както можете да видите от диаграмата по-горе, в нашия случай един екземпляр на Node JS изпълнява две функции: SSR и „прокси“ в API, където се извършва оторизацията на потребителя. Това обстоятелство прави невъзможно оторизирането, докато JS кодът се изпълнява на сървъра, тъй като възелът е еднонишков и SSR функцията е синхронна. Тоест сървърът просто не може да изпраща заявки към себе си, докато стекът за извиквания е зает с нещо. Оказа се, че актуализирахме състоянието, но интерфейсът не спря да потрепва, тъй като данните на клиента трябваше да се актуализират, като се вземе предвид потребителската сесия. Трябваше да научим нашето приложение да поставя правилните данни в първоначалното състояние, като взема предвид данните за вход на потребителя.

Имаше само две решения на проблема:

• прикачете данни за оторизация към междусървърни заявки;
• разделя Node JS слоевете на два отделни екземпляра.

Първото решение изисква използването на глобални променливи на сървъра, а второто удължава срока за изпълнение на задачата с поне месец.

Как да направим избор? Habr често се движи по пътя на най-малкото съпротивление. Неформално има общо желание цикълът от идея до прототип да се намали до минимум. Моделът на отношение към продукта донякъде напомня постулатите на booking.com, с единствената разлика, че Habr приема обратната връзка с потребителите много по-сериозно и се доверява на вас като разработчик да вземате такива решения.

Следвайки тази логика и собственото си желание за бързо решаване на проблема, избрах глобални променливи. И както често се случва, рано или късно трябва да платите за тях. Платихме почти веднага: работихме през уикенда, изчистихме последствията, писахме след смъртта и започна да разделя сървъра на две части. Грешката беше много глупава и свързаната с нея грешка не беше лесна за възпроизвеждане. И да, жалко за това, но по един или друг начин, спъвайки се и стенейки, моят PoC с глобални променливи въпреки това влезе в производство и работи доста успешно, докато чака преминаването към нова архитектура с „дву възела“. Това беше важна стъпка, защото формално целта беше постигната - SSR се научи да доставя напълно готова за използване страница и потребителският интерфейс стана много по-спокоен.

Mobile Habr интерфейс след първия етап на рефакторинг

В крайна сметка SSR-CSR архитектурата на мобилната версия води до тази картина:

Верига SSR-CSR с два възела. Node JS API е винаги готов за асинхронен I/O и не е блокиран от SSR функцията, тъй като последната се намира в отделен екземпляр. Верига на заявка #3 не е необходима.

Премахване на дублиращи се заявки

След извършените манипулации първоначалното изобразяване на страницата вече не провокира епилепсия. Но по-нататъшното използване на Habr в режим SPA все още предизвика объркване.

Тъй като основата на потребителския поток са преходите на формата списък със статии → статия → коментари и обратното, беше важно да се оптимизира потреблението на ресурси на тази верига на първо място.

Връщането към емисията за публикации провокира нова заявка за данни

Нямаше нужда да копаем дълбоко. В скрийнкаста по-горе можете да видите, че приложението повторно изисква списъка със статии при плъзгане назад и по време на заявката не виждаме статиите, което означава, че предишните данни изчезват някъде. Изглежда, че компонентът на списъка със статии използва локално състояние и го губи при унищожаване. Всъщност приложението използва глобално състояние, но архитектурата на Vuex е изградена директно: модулите са свързани със страници, които от своя страна са свързани с маршрути. Освен това всички модули са „за еднократна употреба“ - всяко следващо посещение на страницата пренаписва целия модул:

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

Като цяло имахме модул Списък със статии, който съдържа обекти от тип Статия и модул PageArticle, което беше разширена версия на обекта Статия, един вид Пълна статия. Като цяло това изпълнение не носи нищо ужасно само по себе си - то е много просто, дори може да се каже наивно, но изключително разбираемо. Ако нулирате модула всеки път, когато промените маршрута, тогава можете дори да живеете с него. Въпреки това, преместването между емисии на статии, например /feed → /all, гарантирано ще изхвърли всичко свързано с личната емисия, тъй като имаме само една Списък със статии, в който трябва да въведете нови данни. Това отново ни води до дублиране на заявки.

След като събрах всичко, което успях да изровя по темата, формулирах ново държавно устройство и го представих на колегите си. Дискусиите бяха дълги, но в крайна сметка аргументите в полза надделяха над съмненията и аз започнах изпълнението.

Логиката на решението се разкрива най-добре в две стъпки. Първо се опитваме да отделим модула Vuex от страниците и да се обвържем директно с маршрути. Да, ще има малко повече данни в магазина, гетерите ще станат малко по-сложни, но няма да зареждаме статии два пъти. За мобилната версия това е може би най-силният аргумент. Ще изглежда нещо подобно:

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

Но какво ще стане, ако списъците със статии могат да се припокриват между множество маршрути и какво ще стане, ако искаме да използваме повторно обектни данни Статия за изобразяване на страницата с публикацията, превръщайки я в Пълна статия? В този случай би било по-логично да се използва такава структура:

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

Списък със статии тук това е просто един вид хранилище на статии. Всички статии, изтеглени по време на потребителската сесия. Ние се отнасяме към тях с най-голямо внимание, защото това е трафик, който може да е изтеглен чрез бол някъде в метрото между станциите и определено не искаме да причиняваме тази болка на потребителя отново, като го принуждаваме да зарежда данни, които вече има изтеглени. Предмет Идентификационни номера на статии е просто масив от идентификатори (като че ли „връзки“) към обекти Статия. Тази структура ви позволява да избегнете дублирането на данни, общи за маршрутите, и повторното използване на обекта Статия когато изобразявате публикационна страница чрез обединяване на разширени данни в нея.

Резултатът от списъка със статии също стана по-прозрачен: компонентът на итератора обикаля масива с идентификатори на статии и изчертава компонента на тийзъра на статията, предавайки идентификатора като опора, а дъщерният компонент на свой ред извлича необходимите данни от Списък със статии. Когато отидете на страницата за публикация, получаваме вече съществуващата дата от Списък със статии, правим заявка за получаване на липсващите данни и просто ги добавяме към съществуващия обект.

Защо този подход е по-добър? Както писах по-горе, този подход е по-щадящ по отношение на изтеглените данни и ви позволява да ги използвате повторно. Но освен това отваря пътя към някои нови възможности, които идеално се вписват в такава архитектура. Например анкетиране и зареждане на статии в емисията, когато се появят. Можем просто да поставим най-новите публикации в „хранилище“ Списък със статии, запишете отделен списък с нови идентификатори в Идентификационни номера на статии и уведомете потребителя за това. Когато щракнем върху бутона „Покажи нови публикации“, просто ще вмъкнем нови идентификатори в началото на масива на текущия списък със статии и всичко ще работи почти магически.

Направете изтеглянето по-приятно

Черешката на тортата за рефакторинг е концепцията за скелети, която прави процеса на изтегляне на съдържание в бавен интернет малко по-малко отвратителен. Нямаше дискусии по този въпрос, пътят от идеята до прототипа отне буквално два часа. Дизайнът на практика се начерта сам и ние научихме нашите компоненти да изобразяват прости, едва трептящи div блокове, докато чакат данни. Субективно този подход към натоварването всъщност намалява количеството хормони на стреса в тялото на потребителя. Скелетът изглежда така:

Хабралоудинг

Отразяване

Работя в Хабре от шест месеца и приятелите ми все още питат: добре, как ви харесва там? Добре, удобно - да. Но има нещо, което прави тази работа различна от другите. Работих в екипи, които бяха напълно безразлични към продукта си, не знаеха и не разбираха кои са техните потребители. Но тук всичко е различно. Тук се чувстваш отговорен за това, което правиш. В процеса на разработване на функция вие частично ставате неин собственик, участвате във всички продуктови срещи, свързани с вашата функционалност, правите предложения и сами вземате решения. Да създадеш продукт, който сам използваш всеки ден, е много готино, но да пишеш код за хора, които вероятно са по-добри в това от теб, е просто невероятно усещане (без сарказъм).

След пускането на всички тези промени получихме положителна обратна връзка и беше много, много приятно. Вдъхновяващо е. Благодаря ти! Пиши повече.

Нека ви напомня, че след глобалните променливи решихме да променим архитектурата и да разпределим прокси слоя в отделен екземпляр. Архитектурата с два възела вече е пусната под формата на публично бета тестване. Сега всеки може да премине към него и да ни помогне да направим мобилния Habr по-добър. Това е всичко за днес. Ще се радвам да отговоря на всички ваши въпроси в коментарите.

Източник: www.habr.com