Ez her gav bala xwe didim ka Habr çawa ji hundur ve hatî saz kirin, karûbar çawa tê saz kirin, têkilî çawa têne saz kirin, kîjan standard têne bikar anîn û kod çawa bi gelemperî li vir têne nivîsandin. Xweşbextane, min derfetek wisa peyda kir, ji ber ku ez vê dawiyê bûm beşek ji tîma habra. Bi karanîna mînakek nûvekirinek piçûk a guhertoya mobîl, ez ê hewl bidim ku bersiva pirsê bidim: xebata li vir li pêşiyê çawa ye. Di bernameyê de: Node, Vue, Vuex û SSR bi sosê ji notên li ser ezmûna kesane ya li Habr.
Yekem tiştê ku hûn hewce ne di derbarê tîmê pêşkeftinê de zanibin ev e ku em hindik in. Ne bes e - ev sê pêş, du paş û pêşengiya teknîkî ya hemî Habr - Baxley in. Bê guman, testerek, sêwiranek, sê Vadim, kelekek mûcîze, pisporek kirrûbirrê û Bumburumên din jî hene. Lê tenê şeş beşdarên rasterast ên çavkaniyên Habr hene. Ev pir kêm e - projeyek bi temaşevanek pir-mîlyon dolar, ku ji derve ve wekî pargîdaniyek mezin xuya dike, di rastiyê de bêtir dişibihe destpêkek xweş û bi avahiyek rêxistinî ya herî guncan.
Mîna gelek pargîdaniyên din ên IT-ê, Habr ramanên Agile, pratîkên CI-yê, û ew hemî ye. Lê li gorî hestên min, Habr wekî berhemek ji berdewamî zêdetir di pêlan de pêş dikeve. Ji ber vê yekê, ji bo çend sprintên li pey hev, em bi xîret kodê kod dikin, sêwiran dikin û ji nû ve sêwiran dikin, tiştek dişkînin û rast dikin, bilêtan çareser dikin û yên nû diafirînin, diavêjin ser çîpekê û xwe berdidin lingan, da ku di dawiyê de taybetmendiyê di nav xwe de derxînin. çêkerî. Û dûv re hinekî bêhnvedanek tê, serdemek ji nû ve pêşvebirinê, dema kirina tiştê ku di çargoşeya "girîng-ne lezgîn" de ye tê.
Bi rastî ev sprinta "derve-demsalê" ye ku dê li jêr were nîqaş kirin. Vê carê ew vesazkirina guhertoya mobîl a Habrê vedihewand. Bi gelemperî, pargîdanî ji wê re hêviyên mezin hene, û di pêşerojê de divê ew li şûna tevahiya zozanên heywanên Habrê bigire û bibe çareseriyek gerdûnî ya cross-platform. Rojek dê sêwirana adaptive, PWA, moda negirêdayî, xwerûkirina bikarhêner, û gelek tiştên din ên balkêş hebin.
Werin em peywirê deynin
Carekê, di stand-upek asayî de, yek ji pêşiyê li ser pirsgirêkên di mîmariya beşa şîroveyên guhertoya mobîl de axivî. Bi vê armancê, me civînek mîkro di forma psîkoterapiya komê de organîze kir. Herkesî bi dorê digotin li kuderê diêşe, her tişt li ser kaxezê tomar dikirin, sempatî dikirin, fehm dikirin, ji bilî ku kesî li çepikan nexist. Encam lîsteyek ji 20 pirsgirêkan bû, ku eşkere kir ku mobîl Habr hîn jî rêyek dûr û dirêj a serkeftinê heye.
Ez di serî de li ser karbidestiya karanîna çavkaniyê û ya ku jê re têkiliyek hêsan tê gotin fikar bûm. Her roj, li ser riya mal-kar-mal, min têlefona xweya kevn dît ku bi bêhêvî hewil dida ku 20 sernivîsan di navberê de nîşan bide. Tiştek weha xuya bû:
Têkiliya Habrê ya mobîl beriya nûvekirinê
Li vir çi diqewime? Bi kurtasî, server rûpela HTML-ê ji her kesî re bi heman rengî re xizmet kir, bêyî ku bikarhêner têketî ye an na. Dûv re xerîdar JS tê barkirin û ji nû ve daneyên pêwîst daxwaz dike, lê ji bo destûrdayînê tê sererast kirin. Yanî bi rastî me du caran heman kar kir. Têkilî dihejand, û bikarhêner bi sed kîlobyte zêde dakêşand. Bi hûrgulî her tişt hê bêtir xezeb xuya dikir.
Plana SSR-CSR ya kevn. Destûrdan tenê di qonaxên C3 û C4 de mimkun e, dema ku Node JS ne mijûl e ku HTML-ê çêbike û dikare daxwazên API-ê wekî proxy bike.
Mîmariya me ya wê demê ji hêla yek ji bikarhênerên Habr ve pir rast hate vegotin:
Guhertoya mobîl şaş e. Ez wisa dibêjim. Têkiliyek tirsnak a SSR û CSR.
Diviyabû em vê yekê bipejirînin, çiqas xemgîn bû.
Min vebijarkan nirxand, bilêtek li Jira bi ravekek di asta "ew niha xirab e, rast bike" çêkir û peywirê bi derbên berfireh veqetand:
- daneyên ji nû ve bikar bînin,
- hejmara ji nû ve kişandinê kêm bike,
- daxwazên dubare ji holê rakin,
- pêvajoya barkirinê bêtir eşkere bikin.
Ka em daneyan ji nû ve bikar bînin
Di teorîyê de, pêşkêşkirina alîyê server-ê ji bo çareserkirina du pirsgirêkan hatîye sêwirandin: ne ku ji sînorên motora lêgerînê di warê û metrîkê baştir bikin (bêguman xirab dibe ). Di senaryoyek klasîk de ku di dawiyê de sal (hîn jî li ser Backbone.js), SSR heman serîlêdana JS ya isomorphîk e ku di hawîrdora Node-yê de tê xebitandin. Pêşkêşkar tenê sêwirana çêkirî wekî bersivek daxwazê dişîne. Dûv re rehydration li aliyê xerîdar çêdibe, û dûv re her tişt bêyî nûvekirina rûpelê dixebite. Ji bo Habr, wekî gelek çavkaniyên din ên bi naveroka nivîsê, pêşkêşkirina serverê di avakirina têkiliyên dostane yên bi motorên lêgerînê re hêmanek girîng e.
Tevî vê rastiyê ku zêdetirî şeş sal di ser hatina teknolojiyê re derbas bûne, û di vê demê de pir av bi rastî di binê pirê de li cîhana pêş-endê diherike, ji bo gelek pêşdebiran ev raman hîn jî di nepenîtiyê de ye. Me xwe neda alîkî û serîlêdanek Vue ya bi piştgiriya SSR-ê ji hilberînê re derxist, yek hûrguliyek piçûk winda kir: me rewşa destpêkê ji xerîdar re neşand.
Çima? Bersiva vê pirsê rast nîne. An wan nexwest ku mezinahiya bersivê ji serverê zêde bikin, an jî ji ber komek pirsgirêkên mîmarî yên din, an jî ew bi hêsanî derneket. Bi rengekî din, avêtina dewletê û ji nû ve karanîna her tiştê ku server kir pir maqûl û kêrhatî xuya dike. Karê bi rastî ne hindik e - di çarçoveya darvekirinê de, û Vue bixweber wê wekî guhêrbarek gerdûnî li sêwirana hatî çêkirin zêde dike: window.__INITIAL_STATE__.
Yek ji pirsgirêkên ku derketiye ew e ku nekaribûna veguheztina strukturên cyclic nav JSON (); bi tenê bi guheztina strukturên weha bi hevpîşeyên xwe yên daîre hate çareser kirin.
Wekî din, dema ku hûn bi naveroka UGC-ê re mijûl dibin, divê hûn ji bîr mekin ku ji bo ku HTML-ê neşikînin divê daneyên li saziyên HTML-ê werin veguheztin. Ji bo van armancan em bikar tînin .
Kêmkirina dubareyan
Wekî ku hûn ji diyagrama li jor dibînin, di rewşa me de, mînakek Node JS du fonksiyonan pêk tîne: SSR û "proxy" di API-yê de, ku destûrnameya bikarhêner pêk tê. Ev rewş dema ku koda JS-ê li ser serverê dimeşîne destûr ne gengaz dike, ji ber ku girêk yek-texlît e, û fonksiyona SSR hevdem e. Ango, server bi tenê nikare daxwazan ji xwe re bişîne dema ku callstack bi tiştek re mijûl e. Derket holê ku me dewlet nûve kir, lê pêvekê dev jê berneda, ji ber ku daneyên li ser xerîdar neçar bû ku li gorî rûniştina bikarhêner were nûve kirin. Me hewce bû ku em serîlêdana xwe hîn bikin ku daneyên rast di rewşa destpêkê de bihêle, têketina bikarhêner li ber çavan bigire.
Ji bo pirsgirêkê tenê du çareserî hebûn:
- daneyên destûrnameyê bi daxwazên cross-server ve girêdin;
- Tebeqeyên Node JS-ê li du mînakên cihê veqetînin.
Çareseriya yekem hewceyê karanîna guhêrbarên gerdûnî yên li ser serverê bû, û ya duyemîn jî maweya qedandina peywirê bi kêmî ve mehek dirêj kir.
Meriv çawa bijartinek çêbike? Habr gelek caran li ser rêya herî kêm berxwedanê dimeşe. Bi awayekî nefermî, daxwazek gelemperî heye ku çerxa ji ramanê berbi prototîpê bi kêmî ve kêm bike. Modela helwêsta li hember hilberê hinekî tîne bîra postulatên booking.com, bi tenê cûdahiya wê ev e ku Habr nerînên bikarhêner pir ciddî digire û ji we re, wekî pêşdebir, bawer dike ku hûn biryarên weha bidin.
Li dû vê mantiqê û xwesteka xwe ya ji bo çareserkirina zû pirsgirêkê, min guherbarên gerdûnî hilbijart. Û, wekî ku pir caran dibe, divê hûn ji bo wan zû an dereng bidin. Me hema hema tavilê drav da: me dawiya hefteyê xebitî, encaman paqij kir, nivîsand û dest bi dabeşkirina serverê kir du beş. Xeletî pir ehmeq bû, û xeletiya ku tê de ye ji nû ve ne hêsan bû. Erê, ji bo vê yekê şerm e, lê bi rengekî din, terpilîn û nalîn, PoC-ya min a bi guhêrbarên gerdûnî dîsa jî ket nav hilberînê û bi serfirazî dixebite dema ku li benda derbasbûna mîmariya nû ya "du-node" ye. Ev gavek girîng bû, ji ber ku bi awayekî fermî armanc hate bidestxistin - SSR fêr bû ku rûpelek bi tevahî amade-karsaziyê radest bike, û UI pir aramtir bû.
Navbera Mobile Habr piştî qonaxa yekem a vesazkirinê
Di dawiyê de, mîmariya SSR-CSR ya guhertoya mobîl ber bi vê wêneyê ve dibe:
Qada SSR-CSR "du-node". Node JS API her gav ji bo I/O asynchronous amade ye û ji hêla fonksiyona SSR ve nayê asteng kirin, ji ber ku ya paşîn di mînakek cûda de cih digire. Zincîra pirsê #3 ne hewce ye.
Rakirina daxwazên dubare
Piştî ku manîpulasyon hatin kirin, vegotina destpêkê ya rûpelê êdî epîlepsiyê provoke nekir. Lê karanîna din a Habr di moda SPA de hîn jî bû sedema tevliheviyê.
Ji ber ku bingeha herikîna bikarhêner veguherînên formê ye lîsteya gotaran → gotar → şîrove û berevajî, girîng bû ku di rêza yekem de vexwarina çavkaniyê ya vê zincîrê xweşbîn kirin.
Vegera ser feed postê daxwazek daneya nû provoke dike
Ne hewce bû ku kûr bikole. Di dîmendera jorîn de hûn dikarin bibînin ku serîlêdan dema ku paşde vedigere navnîşa gotaran ji nû ve daxwaz dike, û di dema daxwazê de em gotaran nabînin, ku tê vê wateyê ku daneyên berê li cîhek winda dibin. Wusa dixuye ku pêkhateya lîsteya gotarê dewletek herêmî bikar tîne û di hilweşandinê de wiya winda dike. Bi rastî, serîlêdanê dewletek gerdûnî bikar anî, lê mîmariya Vuex bi serê xwe hate çêkirin: modul bi rûpelan ve têne girêdan, ku di encamê de bi rêgezan ve têne girêdan. Digel vê yekê, hemî modul "desthilatdar" in - her serdanek paşîn a rûpelê tevahiya modulê ji nû ve nivîsand:
ArticlesList: [
{ Article1 },
...
],
PageArticle: { ArticleFull1 },
Bi tevahî, me modulek hebû GotarList, ku tiştên cureyê hene Tişt û module PageArticle, ku versiyonek dirêjkirî ya objektê bû Tişt, cûreyek ArticleFull. Bi gelemperî, ev pêkanîn bi serê xwe tiştek tirsnak hilnagire - ew pir hêsan e, meriv dikare bêje naîf jî, lê zehf têgihîştî ye. Ger hûn her carê ku hûn rêyê diguherînin modulê ji nû ve saz bikin, wê hingê hûn dikarin pê re jî bijîn. Lêbelê, ji bo nimûne, di navbera xwarinên gotarê de digerin /xwarin → /hemû, garantî ye ku meriv her tiştê ku bi xwarina kesane ve girêdayî ye bavêje, ji ber ku em tenê yek heye GotarList, ku hûn hewce ne ku daneyên nû têxin hundur. Ev dîsa me dibe sedema dubarekirina daxwazan.
Piştî ku min her tiştê ku min karîbû li ser mijarê bikolim berhev kir, min avahiyek nû ya dewletê ava kir û pêşkêşî hevkarên xwe kir. Gotûbêj dirêj bûn, lê di dawiyê de argumanên di berjewendiyê de ji gumanan zêdetir bûn, û min dest bi cîbicîkirinê kir.
Mantiqa çareseriyê herî baş di du gavan de derdikeve holê. Pêşî em hewl didin ku modula Vuex ji rûpelan veqetînin û rasterast bi rêgezan ve girêbidin. Erê, dê di firotgehê de piçek bêtir dane hebin, wergir dê hinekî tevlihevtir bibin, lê em ê gotaran du caran bar nekin. Ji bo guhertoya mobîl, ev dibe ku argumana herî xurt e. Ew ê tiştek wusa xuya bike:
ArticlesList: {
ROUTE_FEED: [
{ Article1 },
...
],
ROUTE_ALL: [
{ Article2 },
...
],
}
Lê çi dibe ku navnîşên gotaran dikarin di navbera gelek rêgezan de li hev bikevin û çi dibe bila bibe heke em dixwazin daneyên tiştan ji nû ve bikar bînin Tişt ji bo ku rûpela postê pêşkêşî bike, lê vegerîne ArticleFull? Di vê rewşê de, ew ê maqûltir be ku meriv avahiyek weha bikar bîne:
ArticlesIds: {
ROUTE_FEED: [ '1', ... ],
ROUTE_ALL: [ '1', '2', ... ],
},
ArticlesList: {
'1': { Article1 },
'2': { Article2 },
...
}
GotarList li vir ew tenê celebek depoyek gotaran e. Hemî gotarên ku di dema rûniştina bikarhêner de hatine daxistin. Em wan bi baldarî tevdigerin, ji ber ku ev seyrûsefer e ku dibe ku di nav metroyê de di navbera qereqolan de bi êşê hatibe dakêşandin, û em bê guman naxwazin ku dîsa vê êşê bidin bikarhêner bi zorê wî ku daneyên ku wî berê bar kiriye daxistin. Tiştek ArticlesIds bi tenê komek nasnameyan e (wek "girêdan") ji tiştan re Tişt. Ev avahî dihêle hûn ji dubarekirina daneya hevpar a rêgezan û ji nû ve karanîna tiştan dûr bixin Tişt dema ku rûpelek posteyê bi berhevkirina daneya dirêjkirî di nav wê de vedihewîne.
Hilberîna navnîşa gotaran jî zelaltir bûye: pêkhateya îterator di nav rêza bi nasnavên gotaran de dubare dike û beşê teaserkirina gotaran dikişîne, Id-yê wekî pêvek derbas dike, û pêkhateya zarok, di encamê de, daneyên pêwîst ji GotarList. Dema ku hûn diçin rûpela weşanê, em ji dîroka berê ya heyî digirin GotarList, em daxwazek dikin ku daneyên winda bi dest bixin û bi tenê wê li tiştê heyî zêde bikin.
Çima ev nêzîkatî çêtir e? Wekî ku min li jor nivîsî, ev nêzîkatî bi rêzgirtina daneyên dakêşandî nermtir e û dihêle hûn wê ji nû ve bikar bînin. Lê ji xeynî vê, rê li ber hin îmkanên nû jî vedike ku bi temamî di nav avahîsaziyek wiha de cih digirin. Mînakî, anket û barkirina gotaran di nav xwarinê de wekî ku xuya dikin. Em dikarin bi tenê postên herî paşîn têxin "defek" GotarList, navnîşek cuda ya nasnameyên nû tê de hilînin ArticlesIds û bikarhêner li ser wê agahdar bikin. Gava ku em li ser bişkoka "Weşanên Nû Nîşan Bide" bikirtînin, em ê bi tenê Nasnameyên nû têxin destpêka rêzika navnîşa gotaran a heyî û her tişt dê hema hema bi sêhrbazî bixebite.
Daxistinê xweştir dikin
Xalê li ser kekê refaktorkirinê têgeha îskeletan e, ku pêvajoya dakêşana naverokê li ser Înternetek hêdî hinekî kêmtir nefret dike. Li ser vê mijarê ti nîqaş nehatin kirin; Sêwiranê bi pratîkî xwe xêz kir, û me hêmanên xwe hîn kir ku dema ku li benda daneyê ne, blokên div sade, ku bi zorê diqelizin bidin. Subjektîf, ev nêzîkatiya barkirinê bi rastî hêjmara hormonên stresê di laşê bikarhêner de kêm dike. Skeleton wiha xuya dike:
Habraloading
Reflecting
Ez şeş mehan li Habré dixebitim û hevalên min hîn jî dipirsin: Baş e, hûn li wir çawa hez dikin? Baş e, rehet - erê. Lê tiştek heye ku vê xebatê ji yên din cuda dike. Min di tîmên ku ji hilberên xwe re bi tevahî bêhêz bûn de xebitî, nizanibû an fam nedikir ku bikarhênerên wan kî ne. Lê li vir her tişt cuda ye. Li vir hûn ji tiştê ku hûn dikin berpirsiyar hîs dikin. Di pêvajoya pêşxistina taybetmendiyekê de, hûn bi qismî dibin xwediyê wê, beşdarî hemî civînên hilberê yên bi fonksiyona we ve girêdayî dibin, pêşniyaran dikin û bi xwe biryaran digirin. Çêkirina hilberek ku hûn bi xwe her roj bikar tînin pir xweş e, lê nivîsandina kodê ji bo kesên ku belkî ji we çêtir di wê de ne tenê hestek bêhempa ye (bê sarkazm).
Piştî berdana van hemî guhertinan, me bersivên erênî wergirtin, û ew pir, pir xweş bû. îlham e. Sipas ji were! Zêdetir binivîsin.
Bihêle ez ji we re bi bîr bînim ku piştî guhêrbarên gerdûnî me biryar da ku mîmariyê biguhezînin û qata proxy-ê di mînakek cûda de veqetînin. Mîmariya "du-node" jixwe di forma ceribandina beta gelemperî de gihîştiye serbestberdanê. Naha her kes dikare wê biguhezîne û ji me re bibe alîkar ku Habr-a mobîl çêtir bikin. Ji bo îro her tişt e. Ez ê kêfxweş bibim ku di şîroveyan de bersiva hemî pirsên we bidim.
Source: www.habr.com