Nimekuwa nikipendezwa na jinsi Habr imeundwa kutoka ndani, jinsi mtiririko wa kazi umeundwa, jinsi mawasiliano yanapangwa, viwango gani vinavyotumiwa na jinsi msimbo kwa ujumla umeandikwa hapa. Kwa bahati nzuri, nilipata nafasi kama hiyo, kwa sababu hivi majuzi nimekuwa sehemu ya timu ya habra. Kwa kutumia mfano wa urekebishaji mdogo wa toleo la rununu, nitajaribu kujibu swali: ni nini kufanya kazi hapa mbele. Katika mpango: Node, Vue, Vuex na SSR na mchuzi kutoka kwa maelezo kuhusu uzoefu wa kibinafsi katika Habr.
Jambo la kwanza unahitaji kujua kuhusu timu ya maendeleo ni kwamba ni wachache wetu. Haitoshi - hizi ni pande tatu, migongo miwili na uongozi wa kiufundi wa wote Habr - Baxley. Kuna, kwa kweli, pia kuna tester, mbuni, Vadim tatu, ufagio wa muujiza, mtaalam wa uuzaji na Bumburums zingine. Lakini kuna wachangiaji sita tu wa moja kwa moja kwa vyanzo vya Habr. Hii ni nadra sana - mradi ulio na hadhira ya mamilioni ya dola, ambayo kutoka nje inaonekana kama biashara kubwa, kwa ukweli inaonekana zaidi kama mwanzo mzuri na muundo wa shirika ulio bora zaidi.
Kama kampuni zingine nyingi za IT, Habr anadai maoni ya Agile, mazoea ya CI, na ndivyo tu. Lakini kulingana na hisia zangu, Habr kama bidhaa inakua zaidi katika mawimbi kuliko kuendelea. Kwa hivyo, kwa sprints kadhaa mfululizo, tunaandika kwa bidii kitu, kubuni na kuunda upya, kuvunja kitu na kukirekebisha, kutatua tikiti na kuunda mpya, kukanyaga reki na kujipiga risasi miguuni, ili hatimaye kutolewa kipengele ndani. uzalishaji. Na kisha inakuja utulivu fulani, kipindi cha kuunda upya, wakati wa kufanya kile kilicho katika roboduara "muhimu-sio ya haraka".
Ni hasa mbio hizi za "off-msimu" ambazo zitajadiliwa hapa chini. Wakati huu ilijumuisha urekebishaji upya wa toleo la rununu la Habr. Kwa ujumla, kampuni ina matumaini makubwa kwa hilo, na katika siku zijazo inapaswa kuchukua nafasi ya zoo nzima ya mwili wa Habr na kuwa suluhisho la msalaba-jukwaa zima. Siku moja kutakuwa na mpangilio unaobadilika, PWA, hali ya nje ya mtandao, ubinafsishaji wa mtumiaji, na mambo mengine mengi ya kuvutia.
Hebu tuweke kazi
Mara moja, kwenye msimamo wa kawaida, mmoja wa mbele alizungumza juu ya shida katika usanifu wa sehemu ya maoni ya toleo la rununu. Kwa kuzingatia hili, tulipanga mkutano mdogo katika muundo wa tiba ya kisaikolojia ya kikundi. Kila mtu alichukua zamu ya kusema pale inapoumiza, walirekodi kila kitu kwenye karatasi, walihurumia, walielewa, isipokuwa hakuna aliyepiga makofi. Matokeo yake yalikuwa orodha ya matatizo 20, ambayo yaliweka wazi kuwa Habr ya simu bado alikuwa na njia ndefu na yenye miiba ya mafanikio.
Kimsingi nilikuwa na wasiwasi juu ya ufanisi wa matumizi ya rasilimali na kile kinachoitwa interface laini. Kila siku, kwenye njia ya nyumbani-kazi ya nyumbani, niliona simu yangu ya zamani ikijaribu kuonyesha vichwa 20 vya habari kwenye mipasho. Ilionekana kitu kama hiki:
Kiolesura cha Mobile Habr kabla ya kugeuza upya
Nini kinaendelea hapa? Kwa kifupi, seva ilihudumia ukurasa wa HTML kwa kila mtu kwa njia ile ile, bila kujali kama mtumiaji alikuwa ameingia au la. Kisha mteja JS hupakiwa na kuomba data muhimu tena, lakini kurekebishwa kwa idhini. Hiyo ni, tulifanya kazi sawa mara mbili. Kiolesura kilififia, na mtumiaji akapakua kilobaiti mia za ziada. Kwa undani kila kitu kilionekana kuwa cha kutisha zaidi.
Mpango wa zamani wa SSR-CSR. Uidhinishaji unawezekana tu katika hatua za C3 na C4, wakati Node JS haijashughulika na kutengeneza HTML na inaweza kutuma maombi ya seva mbadala kwa API.
Usanifu wetu wa wakati huo ulielezewa kwa usahihi sana na mmoja wa watumiaji wa Habr:
Toleo la rununu ni ujinga. Ninaiambia kama ilivyo. Mchanganyiko wa kutisha wa SSR na CSR.
Ilibidi tukubali, haijalishi ni huzuni jinsi gani.
Nilitathmini chaguo, nikaunda tikiti katika Jira yenye maelezo katika kiwango cha "ni mbaya sasa, fanya sawa" na nikatenganisha kazi hiyo kwa mapana:
- tumia tena data,
- punguza idadi ya michoro upya,
- ondoa maombi yanayorudiwa,
- fanya mchakato wa upakiaji kuwa wazi zaidi.
Wacha tutumie data tena
Kwa nadharia, utoaji wa upande wa seva umeundwa kutatua shida mbili: sio kuteseka na mapungufu ya injini ya utaftaji kulingana na na kuboresha kipimo (inazidi kuwa mbaya ) Katika hali ya kawaida ambayo hatimaye mwaka (bado iko kwenye Backbone.js), SSR ni programu sawa ya isomorphic JS inayoendesha katika mazingira ya Node. Seva hutuma tu mpangilio uliotengenezwa kama jibu la ombi. Kisha rehydration hutokea kwa upande wa mteja, na kisha kila kitu hufanya kazi bila upakiaji wa ukurasa. Kwa Habr, kama ilivyo kwa nyenzo zingine nyingi zilizo na maandishi, uwasilishaji wa seva ni kipengele muhimu katika kujenga uhusiano wa kirafiki na injini za utafutaji.
Licha ya ukweli kwamba zaidi ya miaka sita imepita tangu ujio wa teknolojia, na wakati huu maji mengi yamepita chini ya daraja katika ulimwengu wa mbele, kwa watengenezaji wengi wazo hili bado limefungwa kwa usiri. Hatukusimama kando na kuzindua programu ya Vue na usaidizi wa SSR kwa uzalishaji, na kukosa maelezo moja ndogo: hatukutuma hali ya awali kwa mteja.
Kwa nini? Hakuna jibu kamili kwa swali hili. Labda hawakutaka kuongeza ukubwa wa majibu kutoka kwa seva, au kwa sababu ya kundi la matatizo mengine ya usanifu, au haikuondoa tu. Njia moja au nyingine, kutupa hali na kutumia tena kila kitu ambacho seva ilifanya inaonekana inafaa kabisa na muhimu. Kwa kweli kazi ni ndogo - kwenye muktadha wa utekelezaji, na Vue inaiongeza kiotomatiki kwenye mpangilio uliotolewa kama kigezo cha kimataifa: window.__INITIAL_STATE__.
Shida moja ambayo imetokea ni kutoweza kubadilisha muundo wa mzunguko kuwa JSON (); ilitatuliwa kwa kubadilisha tu miundo kama hiyo na wenzao wa gorofa.
Kwa kuongeza, unaposhughulika na maudhui ya UGC, unapaswa kukumbuka kuwa data inapaswa kubadilishwa kwa vyombo vya HTML ili usivunje HTML. Kwa madhumuni haya tunatumia .
Kupunguza michoro upya
Kama unavyoona kutoka kwenye mchoro hapo juu, kwa upande wetu, mfano mmoja wa Node JS hufanya kazi mbili: SSR na "proksi" katika API, ambapo idhini ya mtumiaji hutokea. Hali hii inafanya kuwa haiwezekani kuidhinisha wakati msimbo wa JS unafanya kazi kwenye seva, kwa kuwa nodi ina nyuzi moja, na kazi ya SSR ni ya kusawazisha. Hiyo ni, seva haiwezi kutuma maombi yenyewe wakati simu iko na kitu. Ilibadilika kuwa tulisasisha hali, lakini interface haikuacha kutetemeka, kwani data kwenye mteja ilibidi kusasishwa kwa kuzingatia kipindi cha mtumiaji. Tulihitaji kufundisha programu yetu kuweka data sahihi katika hali ya awali, kwa kuzingatia kuingia kwa mtumiaji.
Kulikuwa na suluhisho mbili tu za shida:
- ambatisha data ya idhini kwa maombi ya seva-tofauti;
- gawanya tabaka za Node JS katika hali mbili tofauti.
Suluhisho la kwanza lilihitaji matumizi ya vigezo vya kimataifa kwenye seva, na la pili liliongeza muda wa mwisho wa kukamilisha kazi kwa angalau mwezi.
Jinsi ya kufanya uchaguzi? Habr mara nyingi huenda kwenye njia ya upinzani mdogo. Kwa njia isiyo rasmi, kuna hamu ya jumla ya kupunguza mzunguko kutoka kwa wazo hadi mfano hadi kiwango cha chini. Mtindo wa mtazamo kuelekea bidhaa unafanana kwa kiasi fulani na machapisho ya booking.com, tofauti pekee ni kwamba Habr huchukulia maoni ya watumiaji kwa uzito zaidi na anakuamini, kama msanidi programu, kufanya maamuzi kama hayo.
Kufuatia mantiki hii na hamu yangu mwenyewe ya kutatua shida haraka, nilichagua anuwai za ulimwengu. Na, mara nyingi hutokea, unapaswa kulipa mapema au baadaye. Tulilipa karibu mara moja: tulifanya kazi mwishoni mwa wiki, tukafuta matokeo, tuliandika na kuanza kugawa seva katika sehemu mbili. Hitilafu ilikuwa ya kijinga sana, na hitilafu inayohusisha haikuwa rahisi kuzaliana. Na ndiyo, ni aibu kwa hili, lakini kwa njia moja au nyingine, kujikwaa na kuugua, PoC yangu yenye vigezo vya kimataifa hata hivyo iliingia katika uzalishaji na inafanya kazi kwa mafanikio kabisa wakati wa kusubiri kuhamia kwa usanifu mpya wa "nodi mbili". Hii ilikuwa hatua muhimu, kwa sababu lengo lilifikiwa rasmi - SSR ilijifunza kutoa ukurasa ulio tayari kabisa kutumika, na UI ikawa shwari zaidi.
Kiolesura cha Habr cha Simu baada ya hatua ya kwanza ya kurekebisha tena
Hatimaye, usanifu wa SSR-CSR wa toleo la simu husababisha picha hii:
οΏΌMzunguko wa "node mbili" SSR-CSR. Node JS API daima iko tayari kwa I/O isiyo ya kawaida na haijazuiwa na kazi ya SSR, kwani ya mwisho iko katika mfano tofauti. Msururu wa hoja #3 hauhitajiki.
Kuondoa maombi yanayorudiwa
Baada ya ghiliba kutekelezwa, utoaji wa awali wa ukurasa haukuchochea tena kifafa. Lakini matumizi zaidi ya Habr katika hali ya SPA bado yalisababisha machafuko.
Kwa kuwa msingi wa mtiririko wa mtumiaji ni mabadiliko ya fomu orodha ya makala β makala β maoni na kinyume chake, ilikuwa muhimu kuboresha matumizi ya rasilimali ya mnyororo huu kwanza.
Kurudi kwa mipasho ya chapisho hukasirisha ombi jipya la data
Hakukuwa na haja ya kuchimba kina. Katika onyesho la skrini hapo juu unaweza kuona kwamba programu huomba tena orodha ya vifungu wakati wa kutelezesha kidole nyuma, na wakati wa ombi hatuoni makala, ambayo ina maana kwamba data ya awali hupotea mahali fulani. Inaonekana kama kijenzi cha orodha ya makala kinatumia jimbo la karibu na huipoteza wakati wa kuharibu. Kwa kweli, maombi yalitumia hali ya kimataifa, lakini usanifu wa Vuex ulijengwa juu ya kichwa: modules zimefungwa kwenye kurasa, ambazo kwa upande wake zimefungwa kwa njia. Zaidi ya hayo, moduli zote "zinaweza kutumika" - kila ziara inayofuata kwenye ukurasa iliandika upya moduli nzima:
ArticlesList: [
{ Article1 },
...
],
PageArticle: { ArticleFull1 },
Kwa jumla, tulikuwa na moduli Orodha ya Makala, ambayo ina vitu vya aina Ibara ya na moduli Makala ya Ukurasa, ambayo ilikuwa toleo la kupanuliwa la kitu Ibara ya, aina Makala Imejaa. Kwa ujumla, utekelezaji huu haubeba chochote kibaya yenyewe - ni rahisi sana, mtu anaweza hata kusema ujinga, lakini inaeleweka sana. Ikiwa utaweka upya moduli kila wakati unapobadilisha njia, basi unaweza kuishi nayo. Hata hivyo, kusonga kati ya milisho ya makala, kwa mfano /kulisha β /wote, imehakikishiwa kutupa kila kitu kinachohusiana na malisho ya kibinafsi, kwa kuwa tunayo moja tu Orodha ya Makala, ambayo unahitaji kuweka data mpya. Hii inatuongoza tena kwa kurudia maombi.
Baada ya kukusanya kila kitu ambacho niliweza kuchimba juu ya mada hiyo, nilitengeneza muundo mpya wa serikali na kuiwasilisha kwa wenzangu. Majadiliano yalikuwa marefu, lakini mwishowe hoja za kuunga mkono zilizidi mashaka, na nikaanza utekelezaji.
Mantiki ya suluhisho imefunuliwa vyema katika hatua mbili. Kwanza tunajaribu kufuta moduli ya Vuex kutoka kwa kurasa na kumfunga moja kwa moja kwenye njia. Ndio, kutakuwa na data zaidi kwenye duka, wapataji watakuwa ngumu zaidi, lakini hatutapakia nakala mara mbili. Kwa toleo la rununu, hii labda ndiyo hoja yenye nguvu zaidi. Itaonekana kitu kama hiki:
ArticlesList: {
ROUTE_FEED: [
{ Article1 },
...
],
ROUTE_ALL: [
{ Article2 },
...
],
}
Lakini vipi ikiwa orodha za makala zinaweza kuingiliana kati ya njia nyingi na vipi ikiwa tunataka kutumia tena data ya kitu Ibara ya ili kutoa ukurasa wa chapisho, kuugeuza kuwa Makala Imejaa? Katika kesi hii, itakuwa busara zaidi kutumia muundo kama huu:
ArticlesIds: {
ROUTE_FEED: [ '1', ... ],
ROUTE_ALL: [ '1', '2', ... ],
},
ArticlesList: {
'1': { Article1 },
'2': { Article2 },
...
}
Orodha ya Makala hapa ni aina tu ya hazina ya nakala. Nakala zote ambazo zilipakuliwa wakati wa kipindi cha mtumiaji. Tunawatendea kwa uangalifu mkubwa, kwa sababu hii ni trafiki ambayo inaweza kupakuliwa kupitia maumivu mahali fulani kwenye metro kati ya vituo, na hakika hatutaki kusababisha maumivu haya kwa mtumiaji tena kwa kumlazimisha kupakia data ambayo tayari anayo. imepakuliwa. Kitu Vitambulisho vya Makala ni safu ya vitambulisho (kana kwamba "viungo") vya vitu Ibara ya. Muundo huu hukuruhusu kuzuia kunakili data ya kawaida kwenye njia na kutumia tena kitu Ibara ya wakati wa kutoa ukurasa wa chapisho kwa kuunganisha data iliyopanuliwa ndani yake.
Toleo la orodha ya vifungu pia limekuwa wazi zaidi: kijenzi cha kirudishi kinarudia kupitia safu iliyo na Vitambulisho vya makala na kuchora kijenzi cha vitekee vya makala, kikipitisha kitambulisho kama kielelezo, na kijenzi cha mtoto, kwa upande wake, hurejesha data muhimu kutoka. Orodha ya Makala. Unapoenda kwenye ukurasa wa uchapishaji, tunapata tarehe iliyopo tayari kutoka Orodha ya Makala, tunatoa ombi la kupata data inayokosekana na kuiongeza tu kwenye kitu kilichopo.
Kwa nini mbinu hii ni bora zaidi? Kama nilivyoandika hapo juu, njia hii ni laini zaidi kwa heshima na data iliyopakuliwa na hukuruhusu kuitumia tena. Lakini kando na hii, inafungua njia ya uwezekano mpya ambao unafaa kabisa katika usanifu kama huo. Kwa mfano, upigaji kura na upakiaji wa makala kwenye mipasho jinsi yanavyoonekana. Tunaweza tu kuweka machapisho ya hivi punde kwenye "hifadhi" Orodha ya Makala, hifadhi orodha tofauti ya vitambulisho vipya ndani Vitambulisho vya Makala na umjulishe mtumiaji kuihusu. Tunapobofya kitufe cha "Onyesha machapisho mapya", tutaingiza tu Vitambulisho vipya kwenye mwanzo wa safu ya orodha ya sasa ya makala na kila kitu kitafanya kazi karibu kichawi.
Kufanya kupakua kufurahisha zaidi
Icing juu ya keki refactoring ni dhana ya mifupa, ambayo inafanya mchakato wa kupakua maudhui kwenye mtandao polepole chini ya kuchukiza kidogo. Hakukuwa na majadiliano juu ya suala hili; njia kutoka kwa wazo hadi mfano ilichukua masaa mawili. Muundo ulijichora, na tulifundisha vijenzi vyetu kutoa vizuizi vya div rahisi, vinavyoyumba sana wakati wa kusubiri data. Kimsingi, mbinu hii ya kupakia hupunguza kiwango cha homoni za mafadhaiko kwenye mwili wa mtumiaji. Mifupa inaonekana kama hii:
Habraloading
Kutafakari
Nimekuwa nikifanya kazi huko Habre kwa miezi sita na marafiki zangu bado wanauliza: vizuri, unapendaje huko? Sawa, vizuri - ndio. Lakini kuna kitu ambacho hufanya kazi hii kuwa tofauti na wengine. Nilifanya kazi katika timu ambazo hazijali kabisa bidhaa zao, sikujua au kuelewa watumiaji wao walikuwa akina nani. Lakini hapa kila kitu ni tofauti. Hapa unajisikia kuwajibika kwa kile unachofanya. Katika mchakato wa kutengeneza kipengele, unakuwa mmiliki wake kwa kiasi, shiriki katika mikutano yote ya bidhaa zinazohusiana na utendakazi wako, toa mapendekezo na ufanye maamuzi mwenyewe. Kutengeneza bidhaa unayotumia kila siku wewe mwenyewe ni nzuri sana, lakini kuandika nambari kwa watu ambao labda ni bora kuliko wewe ni hisia nzuri tu (hakuna kejeli).
Baada ya kutolewa kwa mabadiliko haya yote, tulipokea maoni mazuri, na ilikuwa nzuri sana. Inatia moyo. Asante! Andika zaidi.
Acha nikukumbushe kwamba baada ya anuwai za ulimwengu tuliamua kubadilisha usanifu na kutenga safu ya wakala kwa mfano tofauti. Usanifu wa "nodi mbili" tayari umefikia kutolewa kwa njia ya majaribio ya beta ya umma. Sasa mtu yeyote anaweza kubadili kuitumia na kutusaidia kufanya Habr ya simu kuwa bora zaidi. Ni hayo tu kwa leo. Nitafurahi kujibu maswali yako yote kwenye maoni.
Chanzo: mapenzi.com