Men har doim Habrning ichkaridan qanday tuzilgani, ish jarayoni qanday tuzilgani, aloqalar qanday tuzilgani, qanday standartlardan foydalanilgani va bu erda kod odatda qanday yozilgani bilan qiziqib kelganman. Yaxshiyamki, men shunday imkoniyatga ega bo'ldim, chunki men yaqinda habra jamoasining bir qismi bo'ldim. Mobil versiyani kichik refaktoring misolidan foydalanib, men savolga javob berishga harakat qilaman: bu erda frontda ishlash qanday? Dasturda: Node, Vue, Vuex va SSR Habrdagi shaxsiy tajriba haqidagi eslatmalardan sousli.
Rivojlanish guruhi haqida bilishingiz kerak bo'lgan birinchi narsa - bizda kam. Yetarli emas - bu uchta front, ikkita orqa va barcha Xabr - Baxleyning texnik etakchisi. Albatta, sinovchi, dizayner, uchta Vadim, mo''jizaviy supurgi, marketing bo'yicha mutaxassis va boshqa Bumburumlar ham bor. Ammo Habr manbalariga faqat oltita to'g'ridan-to'g'ri hissa qo'shuvchilar bor. Bu juda kamdan-kam uchraydi - ko'p millionli auditoriyaga ega bo'lgan loyiha tashqaridan ulkan korxonaga o'xshaydi, aslida esa iloji boricha tekis tashkiliy tuzilmaga ega qulay startapga o'xshaydi.
Boshqa ko'plab IT kompaniyalari singari, Habr ham Agile g'oyalari, CI amaliyotlarini tan oladi va bu hammasi. Ammo mening his-tuyg'ularimga ko'ra, Habr mahsulot sifatida doimiy emas, balki to'lqinlarda ko'proq rivojlanmoqda. Shunday qilib, ketma-ket bir nechta sprintlar uchun biz biron bir narsani sinchkovlik bilan kodlaymiz, loyihalashtiramiz va qayta ishlab chiqamiz, nimanidir buzamiz va tuzatamiz, chiptalarni hal qilamiz va yangilarini yaratamiz, rakega qadam qo'yamiz va o'zimizni oyoqlarimizga otamiz, natijada xususiyatni oxirigacha qo'yib yuboramiz. ishlab chiqarish. Va keyin ma'lum bir sukunat, qayta rivojlanish davri, "muhim - shoshilinch emas" kvadrantida bo'lgan narsani qilish vaqti keladi.
Aynan shu "mavsumdan tashqari" sprint quyida muhokama qilinadi. Bu safar u Habrning mobil versiyasini qayta tiklashni o'z ichiga oldi. Umuman olganda, kompaniya bunga katta umid bog'laydi va kelajakda u Xabrning mujassamlangan hayvonot bog'ini almashtirishi va universal kross-platforma yechimiga aylanishi kerak. Bir kuni adaptiv tartib, PWA, oflayn rejim, foydalanuvchini sozlash va boshqa ko'plab qiziqarli narsalar bo'ladi.
Keling, vazifani belgilaymiz
Bir marta, oddiy stendda, oldingilardan biri mobil versiyaning sharhlar komponenti arxitekturasidagi muammolar haqida gapirdi. Shularni hisobga olib, guruh psixoterapiyasi formatida mikro-uchrashuv tashkil etdik. Hamma navbatma-navbat qayerda og'riyotganini aytdi, hammasini qog'ozga tushirdi, hamdardlik bildirdi, tushundi, faqat hech kim qarsak chalmadi. Natijada 20 ta muammolar ro'yxati paydo bo'ldi, bu mobil Habr hali muvaffaqiyatga erishish uchun uzoq va qiyin yo'lni bosib o'tganligini aniq ko'rsatdi.
Men birinchi navbatda resurslardan foydalanish samaradorligi va silliq interfeys deb ataladigan narsa haqida qayg'urardim. Har kuni uy-ish-uy yo'nalishida eski telefonim tasmada 20 ta sarlavhani ko'rsatishga astoydil harakat qilayotganini ko'rdim. Bu shunday ko'rinardi:
Refaktoringdan oldin Mobile Habr interfeysi
Bu yerda nima bo'lyapti? Xulosa qilib aytganda, foydalanuvchi tizimga kirganmi yoki yo'qmi, server HTML sahifasini hammaga bir xil tarzda xizmat qildi. Keyin mijoz JS yuklanadi va yana kerakli ma'lumotlarni so'raydi, lekin avtorizatsiya uchun sozlanadi. Ya'ni, biz aslida bir ishni ikki marta qildik. Interfeys miltilladi va foydalanuvchi yaxshi yuzlab qo'shimcha kilobaytni yuklab oldi. Tafsilotlarda hamma narsa yanada dahshatli ko'rinardi.
Eski SSR-CSR sxemasi. Avtorizatsiya faqat C3 va C4 bosqichlarida, Node JS HTML yaratish bilan band bo'lmaganda va API so'rovlarini proksi-server orqali yuborishi mumkin bo'lganda mumkin.
O'sha davrdagi arxitekturamiz Habr foydalanuvchilaridan biri tomonidan juda aniq tasvirlangan:
Mobil versiyasi ahmoq. Men buni xuddi shunday aytaman. SSR va CSR ning dahshatli kombinatsiyasi.
Qanchalik achinarli bo'lmasin, buni tan olishimiz kerak edi.
Men variantlarni baholadim, Jira-da "endi yomon, buni to'g'ri bajaring" darajasidagi tavsif bilan chipta yaratdim va vazifani keng chiziq bilan ajratdim:
- ma'lumotlarni qayta ishlatish,
- qayta chizish sonini minimallashtirish,
- takroriy so'rovlarni yo'q qilish,
- yuklash jarayonini yanada aniqroq qilish.
Keling, ma'lumotlarni qayta ishlatamiz
Nazariy jihatdan, server tomonida renderlash ikkita muammoni hal qilish uchun mo'ljallangan: qidiruv tizimining cheklovlari nuqtai nazaridan azoblanmaslik. va ko'rsatkichni yaxshilash (muqarrar ravishda yomonlashadi ). Klassik stsenariyda bu nihoyat yil (hali ham Backbone.js da), SSR tugun muhitida ishlaydigan bir xil izomorf JS ilovasidir. Server shunchaki yaratilgan tartibni so'rovga javob sifatida yuboradi. Keyin regidratsiya mijoz tomonida sodir bo'ladi va keyin hamma narsa sahifani qayta yuklamasdan ishlaydi. Habr uchun, matn tarkibiga ega ko'plab boshqa manbalar kabi, serverni ko'rsatish qidiruv tizimlari bilan do'stona munosabatlarni o'rnatishda muhim element hisoblanadi.
Texnologiya paydo bo'lganidan beri olti yildan ko'proq vaqt o'tganiga va shu vaqt ichida front-end dunyosida ko'prik ostidan juda ko'p suv oqib o'tganiga qaramay, ko'plab ishlab chiquvchilar uchun bu g'oya hanuzgacha sir bo'lib qolmoqda. Biz chetda turmadik va ishlab chiqarishga SSR qo'llab-quvvatlanadigan Vue ilovasini chiqardik, bunda bitta kichik tafsilotni yo'qotdik: biz mijozga dastlabki holatni yubormadik.
Nega? Bu savolga aniq javob yo'q. Yoki ular serverdan javob hajmini oshirishni xohlamadilar yoki boshqa bir qator arxitektura muammolari tufayli yoki bu shunchaki o'chmadi. Qanday bo'lmasin, holatni o'chirish va server qilgan hamma narsani qayta ishlatish juda mos va foydali ko'rinadi. Vazifa aslida ahamiyatsiz - ijro kontekstiga kiradi va Vue uni avtomatik ravishda global o'zgaruvchi sifatida yaratilgan tartibga qo'shadi: window.__INITIAL_STATE__.
Yuzaga kelgan muammolardan biri tsiklik tuzilmalarni JSON ga aylantira olmaslikdir (); oddiygina bunday tuzilmalarni tekis hamkasblari bilan almashtirish orqali hal qilindi.
Bundan tashqari, UGC tarkibi bilan ishlashda, HTMLni buzmaslik uchun ma'lumotlar HTML ob'ektlariga aylantirilishi kerakligini yodda tutishingiz kerak. Ushbu maqsadlar uchun biz foydalanamiz .
Qayta chizishni minimallashtirish
Yuqoridagi diagrammadan ko'rinib turibdiki, bizning holatlarimizda bitta Node JS nusxasi ikkita funktsiyani bajaradi: SSR va APIda "proksi", bu erda foydalanuvchi avtorizatsiyasi sodir bo'ladi. Bu holat serverda JS kodi ishlayotgan vaqtda avtorizatsiya qilishni imkonsiz qiladi, chunki tugun bir tarmoqli va SSR funksiyasi sinxrondir. Ya'ni, qo'ng'iroqlar to'plami biror narsa bilan band bo'lsa, server o'ziga so'rov yubora olmaydi. Ma'lum bo'lishicha, biz holatni yangiladik, ammo interfeys burishishni to'xtatmadi, chunki mijoz haqidagi ma'lumotlar foydalanuvchi sessiyasini hisobga olgan holda yangilanishi kerak edi. Biz ilovamizga foydalanuvchi loginini hisobga olgan holda to'g'ri ma'lumotlarni dastlabki holatga qo'yishni o'rgatishimiz kerak edi.
Muammoning faqat ikkita echimi bor edi:
- avtorizatsiya ma'lumotlarini serverlararo so'rovlarga qo'shish;
- Node JS qatlamlarini ikkita alohida misolga bo'ling.
Birinchi yechim serverda global o'zgaruvchilardan foydalanishni talab qildi, ikkinchisi esa vazifani bajarish muddatini kamida bir oyga uzaytirdi.
Qanday qilib tanlov qilish kerak? Habr ko'pincha eng kam qarshilik yo'li bo'ylab harakatlanadi. Norasmiy ravishda, g'oyadan prototipgacha bo'lgan tsiklni minimal darajaga qisqartirish istagi mavjud. Mahsulotga munosabat modeli biroz booking.com postulatlarini eslatadi, yagona farq shundaki, Xabr foydalanuvchilarning fikr-mulohazalariga jiddiyroq yondashadi va bunday qarorlar qabul qilishda dasturchi sifatida sizga ishonadi.
Ushbu mantiqdan va muammoni tezda hal qilish istagimdan kelib chiqib, men global o'zgaruvchilarni tanladim. Va tez-tez sodir bo'lganidek, siz ular uchun ertami-kechmi to'lashingiz kerak. Biz deyarli darhol to'ladik: biz dam olish kunlari ishladik, oqibatlarini bartaraf qildik, yozdik va serverni ikki qismga bo'lishni boshladi. Xato juda ahmoq edi va u bilan bog'liq xatoni takrorlash oson emas edi. Ha, bu sharmandalik, lekin qandaydir tarzda, qoqilib, nola qilib, global o'zgaruvchilarga ega mening PoC ishlab chiqarishga kirdi va yangi "ikki tugunli" arxitekturaga o'tishni kutib, juda muvaffaqiyatli ishlamoqda. Bu muhim qadam edi, chunki rasmiy ravishda maqsadga erishildi - SSR to'liq foydalanishga tayyor sahifani yetkazib berishni o'rgandi va UI ancha tinchlandi.
Refaktoringning birinchi bosqichidan keyin mobil Habr interfeysi
Oxir-oqibat, mobil versiyaning SSR-CSR arxitekturasi ushbu rasmga olib keladi:
"Ikki tugunli" SSR-CSR sxemasi. Node JS API har doim asinxron kiritish-chiqarish uchun tayyor va SSR funksiyasi tomonidan bloklanmaydi, chunki ikkinchisi alohida instansiyada joylashgan. №3 so'rovlar zanjiri kerak emas.
Ikki nusxadagi so'rovlarni yo'q qilish
Manipulyatsiyalar amalga oshirilgandan so'ng, sahifaning dastlabki ko'rsatilishi endi epilepsiyani qo'zg'atmadi. Ammo Habr-dan SPA rejimida foydalanish hali ham chalkashliklarga sabab bo'ldi.
Chunki foydalanuvchi oqimining asosini shaklning o'tishlari tashkil qiladi maqolalar ro'yxati → maqola → sharhlar va aksincha, birinchi navbatda, ushbu zanjirning resurs iste'molini optimallashtirish muhim edi.
Post tasmasiga qaytish yangi maʼlumotlar soʻrovini keltirib chiqaradi
Chuqur qazishning hojati yo'q edi. Yuqoridagi skrinshotda ilova orqaga surilganda maqolalar roʻyxatini qayta soʻrashini va soʻrov davomida biz maqolalarni koʻrmasligimizni koʻrishingiz mumkin, yaʼni oldingi maʼlumotlar qayerdadir yoʻqoladi. Maqola ro'yxati komponenti mahalliy holatni ishlatadi va uni yo'q qilishda yo'qotadi. Aslida, dastur global holatdan foydalangan, biroq Vuex arxitekturasi boshdan-oyoq qurilgan: modullar sahifalarga bog'langan, ular o'z navbatida marshrutlarga bog'langan. Bundan tashqari, barcha modullar "bir martalik" - sahifaga har bir keyingi tashrif butun modulni qayta yozadi:
ArticlesList: [
{ Article1 },
...
],
PageArticle: { ArticleFull1 },
Umuman olganda, bizda modul bor edi Maqolalar roʻyxati, unda turdagi ob'ektlar mavjud Maqola va modul Sahifa maqolasi, bu ob'ektning kengaytirilgan versiyasi edi Maqola, kabi; singari Maqola to'liq. Umuman olganda, bu amalga oshirish o'z-o'zidan hech qanday dahshatli narsaga olib kelmaydi - bu juda oddiy, hatto sodda deyish mumkin, ammo juda tushunarli. Agar siz har safar marshrutni o'zgartirganingizda modulni qayta o'rnatsangiz, u bilan hatto yashashingiz mumkin. Biroq, masalan, maqola tasmalari orasida harakat qilish /feed → /barchasi, shaxsiy tasma bilan bog'liq hamma narsani tashlash kafolatlanadi, chunki bizda faqat bitta Maqolalar roʻyxati, unga yangi ma'lumotlarni kiritishingiz kerak. Bu bizni yana so'rovlarning takrorlanishiga olib keladi.
Mavzu bo'yicha o'rganishim mumkin bo'lgan hamma narsani to'plab, men yangi davlat tuzilmasini shakllantirdim va uni hamkasblarimga taqdim etdim. Munozaralar uzoq davom etdi, lekin oxir-oqibat foydasiga bo'lgan dalillar shubhalardan ustun keldi va men amalga oshirishni boshladim.
Yechim mantig'i eng yaxshi ikki bosqichda ochiladi. Avval biz Vuex modulini sahifalardan ajratishga harakat qilamiz va to'g'ridan-to'g'ri marshrutlarga bog'laymiz. Ha, do'konda biroz ko'proq ma'lumotlar bo'ladi, oluvchilar biroz murakkablashadi, lekin biz maqolalarni ikki marta yuklamaymiz. Mobil versiya uchun bu, ehtimol, eng kuchli dalildir. Bu shunday ko'rinadi:
ArticlesList: {
ROUTE_FEED: [
{ Article1 },
...
],
ROUTE_ALL: [
{ Article2 },
...
],
}
Agar maqola ro'yxatlari bir nechta marshrutlar o'rtasida bir-biriga mos kelishi mumkin bo'lsa va biz ob'ekt ma'lumotlarini qayta ishlatmoqchi bo'lsak-chi? Maqola post sahifasini ko'rsatish, uni aylantirish Maqola to'liq? Bunday holda, bunday tuzilmadan foydalanish mantiqiyroq bo'ladi:
ArticlesIds: {
ROUTE_FEED: [ '1', ... ],
ROUTE_ALL: [ '1', '2', ... ],
},
ArticlesList: {
'1': { Article1 },
'2': { Article2 },
...
}
Maqolalar roʻyxati bu yerda faqat maqolalar omborining bir turi. Foydalanuvchi sessiyasi davomida yuklab olingan barcha maqolalar. Biz ularga juda ehtiyotkorlik bilan munosabatda bo'lamiz, chunki bu stansiyalar orasidagi metroda og'riq tufayli yuklab olingan bo'lishi mumkin bo'lgan tirbandlik va biz foydalanuvchini allaqachon mavjud bo'lgan ma'lumotlarni yuklashga majburlash orqali yana bu og'riqni keltirib chiqarmoqchi emasmiz. yuklab olingan. Ob'ekt Maqolalar identifikatorlari bu shunchaki ob'ektlarga identifikatorlar majmuasi ("bog'lanish" kabi). Maqola. Ushbu tuzilma marshrutlar uchun umumiy ma'lumotlarni takrorlashdan va ob'ektni qayta ishlatishdan qochish imkonini beradi Maqola kengaytirilgan ma'lumotlarni birlashtirish orqali post sahifasini ko'rsatishda.
Maqolalar ro'yxatining chiqishi ham shaffofroq bo'ldi: iterator komponenti maqola identifikatorlari bilan massiv bo'ylab takrorlanadi va maqola tizer komponentini chizadi, Idni rekvizit sifatida uzatadi va bola komponent, o'z navbatida, kerakli ma'lumotlarni oladi. Maqolalar roʻyxati. Nashr sahifasiga kirganingizda, biz allaqachon mavjud sanani olamiz Maqolalar roʻyxati, biz etishmayotgan ma'lumotlarni olish uchun so'rov yuboramiz va uni mavjud ob'ektga qo'shamiz.
Nima uchun bu yondashuv yaxshiroq? Yuqorida yozganimdek, ushbu yondashuv yuklab olingan ma'lumotlarga nisbatan yumshoqroq va uni qayta ishlatishga imkon beradi. Ammo bundan tashqari, bunday arxitekturaga juda mos keladigan ba'zi yangi imkoniyatlarga yo'l ochadi. Misol uchun, so'rovnoma va maqolalarni ular paydo bo'lganda tasmaga yuklash. Biz shunchaki so'nggi xabarlarni "saqlash" ga qo'yishimiz mumkin Maqolalar roʻyxati, yangi identifikatorlarning alohida ro'yxatini saqlang Maqolalar identifikatorlari va foydalanuvchini bu haqda xabardor qiling. "Yangi nashrlarni ko'rsatish" tugmasini bosganimizda, joriy maqolalar ro'yxatining boshiga shunchaki yangi identifikatorlarni kiritamiz va hamma narsa deyarli sehrli ishlaydi.
Yuklab olishni yanada qiziqarli qilish
Refaktoring tortida muzlash skeletlari tushunchasi bo'lib, sekin Internetda kontentni yuklab olish jarayonini biroz jirkanch qiladi. Bu masala bo'yicha hech qanday munozaralar bo'lmadi; g'oyadan prototipgacha bo'lgan yo'l tom ma'noda ikki soat davom etdi. Dizayn amalda o'zini o'zi chizdi va biz komponentlarimizga ma'lumotni kutayotganda oddiy, deyarli miltillovchi div bloklarini ko'rsatishni o'rgatdi. Subyektiv ravishda, yuklashning bunday yondashuvi aslida foydalanuvchining tanasida stress gormonlari miqdorini kamaytiradi. Skelet quyidagicha ko'rinadi:
Habraloading
Mulohaza yuritish
Men Habreda olti oy ishlayapman va do'stlarim hali ham so'rashadi: yaxshi, u erda sizga qanday yoqadi? Yaxshi, qulay - ha. Ammo bu ishni boshqalardan ajratib turadigan bir narsa bor. Men o'z mahsulotiga mutlaqo befarq bo'lgan, foydalanuvchilari kimligini bilmagan yoki tushunmaydigan jamoalarda ishladim. Ammo bu erda hamma narsa boshqacha. Bu erda siz qilgan ishingiz uchun javobgarlikni his qilasiz. Funktsiyani ishlab chiqish jarayonida siz qisman uning egasiga aylanasiz, o'zingizning funksionalligingiz bilan bog'liq barcha mahsulot yig'ilishlarida qatnashasiz, takliflar kiritasiz va o'zingiz qaror qabul qilasiz. Har kuni foydalanadigan mahsulotni o'zingiz yasash juda zo'r, lekin sizdan ko'ra yaxshiroq bo'lgan odamlar uchun kod yozish shunchaki aql bovar qilmaydigan tuyg'u (iste'molsiz).
Ushbu o'zgarishlarning barchasi chiqqandan so'ng, biz ijobiy fikr-mulohazalarni oldik va bu juda va juda yoqimli edi. Bu ilhomlantiradi. Rahmat! Ko'proq yozing.
Eslatib o'taman, global o'zgaruvchilardan so'ng biz arxitekturani o'zgartirishga va proksi-qatlamni alohida misolga ajratishga qaror qildik. "Ikki tugunli" arxitektura allaqachon ommaviy beta-sinov shaklida chiqarildi. Endi har kim unga o'tishi va mobil Habr-ni yaxshilashga yordam berishi mumkin. Bugun uchun hammasi shu. Izohlarda barcha savollaringizga javob berishdan xursand bo'laman.
Manba: www.habr.com