Ég hef alltaf haft áhuga á því hvernig Habr er byggt upp innan frá, hvernig vinnuflæðið er byggt upp, hvernig samskiptum er háttað, hvaða staðlar eru notaðir og hvernig kóði er almennt skrifaður hér. Sem betur fer fékk ég slíkt tækifæri, því ég varð nýlega hluti af habra-liðinu. Með því að nota dæmi um litla endurnýjun farsímaútgáfunnar mun ég reyna að svara spurningunni: hvernig er að vinna hér að framan. Í dagskránni: Node, Vue, Vuex og SSR með sósu úr athugasemdum um persónulega reynslu í Habr.
Það fyrsta sem þú þarft að vita um þróunarteymið er að við erum fáir. Ekki nóg með þetta - þetta eru þrír framhliðar, tveir bakverðir og tæknilegt forskot allra Habr - Baxley. Þarna er auðvitað líka prófari, hönnuður, þrír Vadim, kraftaverkakústur, markaðsfræðingur og aðrir Bumburum. En það eru aðeins sex beinir þátttakendur í heimildum Habr. Þetta er frekar sjaldgæft - verkefni með margra milljóna dollara áhorfendur, sem að utan lítur út eins og risastórt fyrirtæki, lítur í raun meira út eins og notalegt gangsetning með flatasta skipulagi sem mögulegt er.
Eins og mörg önnur upplýsingatæknifyrirtæki, játar Habr liprar hugmyndir, CI starfshætti og það er allt. En samkvæmt mínum tilfinningum er Habr sem vara að þróast meira í bylgjum en stöðugt. Þannig að í nokkra spretti í röð kóðum við eitthvað af kostgæfni, hönnum og endurhönnum, brjótum eitthvað og lagum það, leysum miða og búum til nýja, stígum á hrífu og skýtum okkur í fæturna, til að loksins sleppa eiginleikanum í framleiðslu. Og svo kemur ákveðin lægð, tímabil enduruppbyggingar, tími til að gera það sem er í „mikilvægum-ekki aðkallandi“ fjórðungnum.
Það er einmitt þessi „off-season“ sprettur sem verður fjallað um hér á eftir. Að þessu sinni innihélt það endurnýjun á farsímaútgáfu Habr. Almennt séð bindur fyrirtækið miklar vonir við það og í framtíðinni ætti það að skipta um allan dýragarðinn í holdgervingum Habr og verða alhliða lausn á vettvangi. Einhvern tíma verður aðlagandi skipulag, PWA, ótengdur háttur, notendaaðlögun og margt annað áhugavert.
Við skulum setja verkefnið
Einu sinni, í venjulegu uppistandi, talaði einn af fremstu mönnum um vandamál í arkitektúr athugasemdahluta farsímaútgáfunnar. Með þetta í huga skipulögðum við örfund í formi hópsálfræðimeðferðar. Allir skiptust á að segja hvar það var sárt, þeir skráðu allt á blað, þeir höfðu samúð, þeir skildu, nema að enginn klappaði. Niðurstaðan var listi yfir 20 vandamál, sem gerði það ljóst að farsíma Habr ætti enn langa og þyrnum stráð leið til árangurs.
Ég hafði fyrst og fremst áhyggjur af auðlindanýtingu og því sem kallað er slétt viðmót. Á hverjum degi, á leiðinni heima-vinnu-heim, sá ég gamla símann minn reyna í örvæntingu að birta 20 fyrirsagnir í straumnum. Það leit eitthvað á þessa leið:
Farsíma Habr tengi fyrir endurnýjun
Hvað er í gangi hér? Í stuttu máli þá þjónaði þjónninn HTML síðunni fyrir alla á sama hátt, óháð því hvort notandinn var skráður inn eða ekki. Þá er viðskiptavinurinn JS hlaðinn og biður um nauðsynleg gögn aftur, en leiðrétt fyrir heimild. Það er að segja, við gerðum í raun sama verkið tvisvar. Viðmótið flökti og notandinn hlaðið niður hátt í hundrað kílóbæti til viðbótar. Í smáatriðum leit allt enn hrollvekjandi út.
Gamalt SSR-CSR kerfi. Heimild er aðeins möguleg á stigum C3 og C4, þegar Node JS er ekki upptekið við að búa til HTML og getur umboðsbeiðnir til API.
Arkitektúr okkar þess tíma var mjög nákvæmlega lýst af einum af Habr notendum:
Farsímaútgáfan er vitleysa. Ég segi það eins og það er. Hræðileg blanda af SSR og CSR.
Við urðum að viðurkenna það, sama hversu sorglegt það var.
Ég lagði mat á valkostina, bjó til miða í Jira með lýsingu á stigi „það er slæmt núna, gerðu það rétt“ og sundurgreindi verkefnið í stórum dráttum:
- endurnýta gögn,
- lágmarka fjölda endurteikninga,
- útrýma tvíteknum beiðnum,
- gera hleðsluferlið augljósara.
Endurnýtum gögnin
Fræðilega séð er flutningur á miðlara hönnuð til að leysa tvö vandamál: að þjást ekki af takmörkunum leitarvéla m.t.t. og bæta mælikvarða (óhjákvæmilega versnar ). Í klassískri atburðarás sem loksins ári (enn á Backbone.js), SSR er sama ísómorfa JS forritið sem keyrir í Node umhverfinu. Miðlarinn sendir einfaldlega útbúið skipulag sem svar við beiðninni. Þá á sér stað vökvavökvi hjá viðskiptavininum og þá virkar allt án endurhleðslu síðna. Fyrir Habr, eins og fyrir mörg önnur úrræði með textainnihald, er flutningur miðlara mikilvægur þáttur í að byggja upp vinsamleg samskipti við leitarvélar.
Þrátt fyrir þá staðreynd að meira en sex ár eru liðin frá tilkomu tækninnar og á þessum tíma hefur mikið vatn runnið undir brúna í framendaheiminum, er þessi hugmynd enn hulin leynd hjá mörgum hönnuðum. Við stóðum ekki til hliðar og settum út Vue forrit með SSR stuðningi til framleiðslu, vantaði eitt smáatriði: við sendum ekki upphafsstöðu til viðskiptavinarins.
Hvers vegna? Það er ekkert nákvæmt svar við þessari spurningu. Annað hvort vildu þeir ekki auka stærð svarsins frá þjóninum, eða vegna fjölda annarra byggingarvandamála, eða það tók einfaldlega ekki af skarið. Með einum eða öðrum hætti virðist það alveg viðeigandi og gagnlegt að henda út ástandi og endurnýta allt sem þjónninn gerði. Verkefnið er í raun léttvægt - inn í framkvæmdarsamhengið og Vue bætir því sjálfkrafa við myndað útlit sem alþjóðlega breytu: window.__INITIAL_STATE__.
Eitt af vandamálunum sem hafa komið upp er vanhæfni til að breyta hringlaga mannvirkjum í JSON (); var leyst með því einfaldlega að skipta út slíkum mannvirkjum fyrir flatar hliðstæður þeirra.
Að auki, þegar þú fjallar um UGC efni, ættir þú að muna að gögnunum ætti að breyta í HTML einingar til að brjóta ekki HTML. Í þessum tilgangi notum við .
Lágmarka endurteikningar
Eins og þú sérð á skýringarmyndinni hér að ofan, í okkar tilviki, framkvæmir eitt Node JS tilvik tvær aðgerðir: SSR og „proxy“ í API, þar sem notendaheimild á sér stað. Þessar aðstæður gera það að verkum að það er ómögulegt að heimila á meðan JS kóðann er í gangi á þjóninum, þar sem hnúturinn er einn-þráður og SSR aðgerðin er samstillt. Það er, þjónninn getur einfaldlega ekki sent beiðnir til sjálfs sín á meðan kallstafurinn er upptekinn við eitthvað. Það kom í ljós að við uppfærðum ástandið, en viðmótið hætti ekki að kippast, þar sem gögnin um biðlarann þurfti að uppfæra með hliðsjón af notendalotunni. Við þurftum að kenna forritinu okkar að setja rétt gögn í upphafsstöðu, að teknu tilliti til innskráningar notandans.
Það voru aðeins tvær lausnir á vandanum:
- hengja heimildargögn við beiðnir yfir netþjóna;
- skiptu Node JS lögum í tvö aðskilin tilvik.
Fyrsta lausnin krafðist notkunar á alþjóðlegum breytum á þjóninum og sú síðari framlengdi frestinn til að klára verkefnið um að minnsta kosti mánuð.
Hvernig á að velja? Habr hreyfist oft eftir braut minnstu mótstöðu. Óformlega er almennur vilji til að minnka hringrásina frá hugmynd til frumgerðar í lágmarki. Viðhorfsmódelið til vörunnar minnir að vissu leyti á staðsetningar booking.com, eini munurinn er sá að Habr tekur athugasemdir notenda mun alvarlegri og treystir þér, sem þróunaraðila, til að taka slíkar ákvarðanir.
Eftir þessari rökfræði og eigin löngun til að leysa vandamálið fljótt, valdi ég alþjóðlegar breytur. Og eins og oft vill verða þarf að borga fyrir þau fyrr eða síðar. Við greiddum nánast strax: við unnum um helgina, hreinsuðum út afleiðingarnar, skrifuðum og byrjaði að skipta þjóninum í tvo hluta. Villan var mjög heimskuleg og villan sem tengdist henni var ekki auðvelt að endurskapa. Og já, það er synd fyrir þetta, en á einn eða annan hátt, hrasandi og stynjandi, fór PoC minn með alþjóðlegum breytum engu að síður í framleiðslu og virkar nokkuð vel á meðan ég bíður eftir flutningi yfir í nýjan „tveggja hnúta“ arkitektúr. Þetta var mikilvægt skref því formlega var markmiðinu náð - SSR lærði að skila fullkomlega tilbúinni síðu og HÍ varð mun rólegra.
Mobile Habr tengi eftir fyrsta stig endurmyndunar
Að lokum leiðir SSR-CSR arkitektúr farsímaútgáfunnar til þessarar myndar:
„Tveggja hnúta“ SSR-CSR hringrás. Node JS API er alltaf tilbúið fyrir ósamstillt I/O og er ekki læst af SSR aðgerðinni, þar sem hið síðarnefnda er staðsett í sérstöku tilviki. Fyrirspurnarkeðju #3 er ekki þörf.
Útrýma tvíteknum beiðnum
Eftir að meðhöndlunin var framkvæmd vakti upphafleg birting síðunnar ekki lengur flogaveiki. En frekari notkun Habr í SPA ham olli samt ruglingi.
Þar sem grunnur notendaflæðis er umbreytingar á forminu greinarlisti → grein → athugasemdir og öfugt, það var mikilvægt að hagræða auðlindanotkun þessarar keðju í fyrsta lagi.
Að fara aftur í póststrauminn kallar fram nýja gagnabeiðni
Það þurfti ekki að grafa djúpt. Í skjávarpinu hér að ofan geturðu séð að forritið biður aftur um lista yfir greinar þegar strjúkt er til baka og meðan á beiðni stendur sjáum við ekki greinarnar, sem þýðir að fyrri gögn hverfa einhvers staðar. Það lítur út fyrir að greinalistahlutinn noti staðbundið ríki og tapi því við eyðingu. Reyndar notaði forritið hnattrænt ástand, en Vuex arkitektúrinn var byggður beint: einingar eru bundnar við síður, sem aftur eru bundnar við leiðir. Þar að auki eru allar einingar „einnota“ - hver síðari heimsókn á síðuna endurskrifaði alla eininguna:
ArticlesList: [
{ Article1 },
...
],
PageArticle: { ArticleFull1 },
Alls vorum við með einingu Greinalisti, sem inniheldur hluti af gerðinni Grein og mát Síðugrein, sem var útbreidd útgáfa af hlutnum Grein, eiginlega GreinFull. Í stórum dráttum ber þessi útfærsla í sjálfu sér ekkert hræðilegt - hún er mjög einföld, má jafnvel segja barnaleg, en ákaflega skiljanleg. Ef þú endurstillir eininguna í hvert skipti sem þú breytir leiðinni geturðu jafnvel lifað með henni. Hins vegar að færa á milli greinastrauma, til dæmis /straumur → /allt, er tryggt að henda öllu sem tengist persónulegu straumnum, þar sem við höfum aðeins eitt Greinalisti, þar sem þú þarft að setja ný gögn. Þetta leiðir okkur aftur til tvítekningar á beiðnum.
Eftir að hafa safnað öllu því sem ég gat grafið upp um efnið, mótaði ég nýtt ríkisskipulag og kynnti það fyrir samstarfsfólki mínu. Umræðurnar voru langar en á endanum vógu rökin fyrir því efasemdir og ég hóf framkvæmdina.
Rökfræði lausnar kemur best í ljós í tveimur skrefum. Fyrst reynum við að aftengja Vuex eininguna frá síðum og bindast beint við leiðir. Já, það verða aðeins meiri gögn í versluninni, getters verða aðeins flóknari, en við munum ekki hlaða greinum tvisvar. Fyrir farsímaútgáfuna eru þetta kannski sterkustu rökin. Það mun líta eitthvað á þessa leið:
ArticlesList: {
ROUTE_FEED: [
{ Article1 },
...
],
ROUTE_ALL: [
{ Article2 },
...
],
}
En hvað ef greinalistar geta skarast á milli margra leiða og hvað ef við viljum endurnýta hlutgagnagögn Grein til að gera færslusíðuna, breyta henni í GreinFull? Í þessu tilviki væri rökréttara að nota slíka uppbyggingu:
ArticlesIds: {
ROUTE_FEED: [ '1', ... ],
ROUTE_ALL: [ '1', '2', ... ],
},
ArticlesList: {
'1': { Article1 },
'2': { Article2 },
...
}
Greinalisti hér er þetta bara eins konar geymsla greina. Allar greinar sem voru sóttar á meðan á notendalotunni stóð. Við komum fram við þá af fyllstu varúð, því þetta er umferð sem gæti hafa verið hlaðið niður í gegnum sársauka einhvers staðar í neðanjarðarlestinni á milli stöðva, og við viljum örugglega ekki valda þessum sársauka fyrir notandann aftur með því að neyða hann til að hlaða inn gögnum sem hann hefur þegar niðurhalað. Hlutur ArticlesIds er einfaldlega fylki auðkenna (eins og ef „tengi“) við hluti Grein. Þessi uppbygging gerir þér kleift að forðast að afrita gögn sem eru algeng á leiðum og endurnýta hlutinn Grein þegar þú gerir færslusíðu með því að sameina útbreidd gögn inn í hana.
Úttak greinalistans hefur einnig orðið gagnsærra: endurtekningarhlutinn endurtekur sig í gegnum fylkið með greinaauðkennum og teiknar greinarútgáfuhlutann, sendir auðkennið sem stoð, og barnhlutinn sækir aftur nauðsynleg gögn frá Greinalisti. Þegar þú ferð á útgáfusíðuna fáum við núverandi dagsetningu frá Greinalisti, gerum við beiðni um að fá gögnin sem vantar og bætum þeim einfaldlega við núverandi hlut.
Hvers vegna er þessi nálgun betri? Eins og ég skrifaði hér að ofan er þessi nálgun mildari með tilliti til niðurhalaðra gagna og gerir þér kleift að endurnýta þau. En fyrir utan þetta opnar það leið að nokkrum nýjum möguleikum sem passa fullkomlega inn í slíkan arkitektúr. Til dæmis, skoða og hlaða greinum inn í strauminn eins og þær birtast. Við getum einfaldlega sett nýjustu færslurnar í „geymslu“ Greinalisti, vistaðu sérstakan lista yfir ný auðkenni í ArticlesIds og tilkynna notandanum um það. Þegar við smellum á hnappinn „Sýna nýjar útgáfur“ munum við einfaldlega setja ný auðkenni inn í upphaf arrays núverandi greinalista og allt mun virka næstum töfrandi.
Gerir niðurhal skemmtilegra
Rúsínan í endurnýjunarkökuna er hugtakið beinagrindur, sem gerir ferlið við að hlaða niður efni á hægu neti aðeins minna ógeðslegt. Það voru engar umræður um þetta mál, leiðin frá hugmynd að frumgerð tók bókstaflega tvær klukkustundir. Hönnunin teiknaði nánast sjálfa sig og við kenndum íhlutunum okkar að gera einfaldar, varla flöktandi div blokkir á meðan beðið er eftir gögnum. Huglægt dregur þessi nálgun við hleðslu í raun úr magni streituhormóna í líkama notandans. Beinagrindin lítur svona út:
Habraloading
Hugleiðing
Ég hef unnið í Habré í sex mánuði og vinir mínir spyrja enn: jæja, hvernig líkar þér það þar? Allt í lagi, þægilegt - já. En það er eitthvað sem gerir þetta verk öðruvísi en önnur. Ég vann í teymum sem voru algjörlega áhugalaus um vöruna þeirra, vissu ekki eða skildu hverjir notendur þeirra voru. En hér er allt öðruvísi. Hér finnur þú ábyrgð á því sem þú gerir. Í því ferli að þróa eiginleika verður þú að hluta til eigandi hans, tekur þátt í öllum vörufundum sem tengjast virkni þinni, kemur með tillögur og tekur ákvarðanir sjálfur. Að búa til vöru sem þú notar á hverjum degi sjálfur er mjög töff, en að skrifa kóða fyrir fólk sem er líklega betra í því en þú er bara ótrúleg tilfinning (engin kaldhæðni).
Eftir að allar þessar breytingar voru gefnar út fengum við jákvæð viðbrögð og það var mjög, mjög gott. Það er hvetjandi. Þakka þér fyrir! Skrifaðu meira.
Leyfðu mér að minna þig á að eftir alþjóðlegar breytur ákváðum við að breyta arkitektúrnum og úthluta umboðslaginu í sérstakt tilvik. „Tveggja hnúta“ arkitektúrinn hefur þegar náð útgáfu í formi opinberrar beta prófunar. Nú getur hver sem er skipt yfir í það og hjálpað okkur að gera farsíma Habr betri. Það er allt í dag. Ég mun vera fús til að svara öllum spurningum þínum í athugasemdunum.
Heimild: www.habr.com