Rwyf bob amser wedi bod â diddordeb mewn sut mae Habr wedi'i strwythuro o'r tu mewn, sut mae'r llif gwaith wedi'i strwythuro, sut mae cyfathrebiadau'n cael eu strwythuro, pa safonau sy'n cael eu defnyddio a sut mae'r cod wedi'i ysgrifennu yma yn gyffredinol. Yn ffodus, cefais y cyfle hwn, oherwydd deuthum yn rhan o'r tîm habra yn ddiweddar. Gan ddefnyddio'r enghraifft o ailffactorio bach o'r fersiwn symudol, byddaf yn ceisio ateb y cwestiwn: sut brofiad yw gweithio ar y rheng flaen yma? Yn y rhaglen: Node, Vue, Vuex a SSR gyda saws o nodiadau am brofiad personol yn Habr.
Y peth cyntaf sydd angen i chi ei wybod am y tîm datblygu yw ein bod ni'n fach. Ychydig yw tri ffrynt, dau gefn ac arweiniad technegol Habr i gyd - Baxley. Wrth gwrs, mae yna hefyd brofwr, dylunydd, tri Vadim, banadl gwyrthiol, marchnatwr a Bumburums eraill. Ond dim ond chwe chyfrannwr uniongyrchol sydd i wefannau Habr. Mae hyn yn eithaf prin - prosiect gyda chynulleidfa gwerth miliynau o ddoleri, sydd ar y tu allan yn edrych fel menter enfawr, mewn gwirionedd yn debycach i gychwyn clyd gyda'r strwythur sefydliadol mwyaf gwastad.
Fel llawer o gwmnïau TG eraill, mae Habr yn arddel syniadau Agile, arferion CI, a dyna i gyd. Ond yn fy marn i, mae Habr fel cynnyrch yn datblygu mewn tonnau yn hytrach nag yn barhaus. Felly, am sawl sbrint yn olynol, rydyn ni'n codio rhywbeth yn ddiwyd, yn dylunio ac yn ailgynllunio, torri rhywbeth a'i drwsio, datrys tocynnau a chreu rhai newydd, camu ar gribin a saethu ein hunain yn y traed er mwyn rhyddhau'r nodwedd o'r diwedd yn y dyfodol. Ac yna daw cyfnod tawel, cyfnod o ailddatblygu, amser i wneud yr hyn sydd yn y cwadrant “pwysig – nid brys”.
Yr union sbrint “oddi ar y tymor” hwn fydd yn cael ei drafod isod. Y tro hwn roedd yn cynnwys ailffactorio fersiwn symudol Habr. Yn gyffredinol, mae gan y cwmni obeithion mawr ar ei gyfer, ac yn y dyfodol dylai ddisodli'r sw cyfan o ymgnawdoliadau Habr a dod yn ddatrysiad traws-lwyfan cyffredinol. Rhywbryd bydd cynllun addasol, PWA, modd all-lein, addasu defnyddwyr, a llawer o bethau diddorol eraill.
Gadewch i ni osod y dasg
Unwaith, mewn stand-yp arferol, siaradodd un o'r blaenau am broblemau ym mhensaernïaeth cydran sylwadau'r fersiwn symudol. Gyda'r awgrym hwn, fe wnaethom drefnu micro-gyfarfod ar ffurf seicotherapi grŵp. Cymerodd pawb eu tro gan ddweud ble roedd yn brifo, fe wnaethon nhw recordio popeth ar bapur, cydymdeimlo, deall, heblaw nad oedd neb yn curo. Y canlyniad oedd rhestr o 20 o broblemau, a oedd yn ei gwneud yn glir bod gan Habr symudol lwybr hir a dyrys i lwyddiant o hyd.
Roeddwn yn pryderu’n bennaf am effeithlonrwydd adnoddau a’r hyn a elwir yn rhyngwyneb llyfn. Bob dydd, ar y llwybr “cartref-gwaith-cartref”, gwelais fy hen ffôn yn daer yn ceisio arddangos 20 pennawd yn y porthiant. Roedd yn edrych rhywbeth fel hyn:
Rhyngwyneb Habr symudol cyn ailffactorio
Beth sy'n digwydd yma? Yn fyr, gwasanaethodd y gweinydd y dudalen HTML i bawb yr un ffordd, ni waeth a oedd y defnyddiwr wedi mewngofnodi ai peidio. Yna mae'r cleient JS yn cael ei lwytho ac yn gofyn am y data angenrheidiol eto, ond y tro hwn wedi'i addasu i'w awdurdodi. Hynny yw, mewn gwirionedd fe wnaethom yr un swydd ddwywaith. Fflachiodd y rhyngwyneb, a dadlwythodd y defnyddiwr gant cilobeit ychwanegol. Yn y manylion, roedd popeth yn edrych hyd yn oed yn fwy iasol.
Hen gynllun SSR-CSR. Dim ond ar gamau C3 a C4 y mae awdurdodiad yn bosibl, pan nad yw Node JS yn brysur yn cynhyrchu HTML ac yn gallu gwneud ceisiadau dirprwy i'r API.
Disgrifiwyd ein pensaernïaeth ar y pryd yn gywir iawn gan un o ddefnyddwyr Habr:
Mae'r fersiwn symudol yn crap. Rwy'n ei ddweud fel y mae. Cyfuniad erchyll o SSR ynghyd â CSR.
Gorfodwyd ni i gyfaddef hyn, ni waeth pa mor drist ydoedd.
Asesais yr opsiynau, creais docyn yn Jira gyda disgrifiad ar y lefel “mae'n ddrwg nawr, gwnewch bethau'n iawn” a dadelfennais y dasg mewn strociau eang:
- ailddefnyddio data,
- lleihau nifer yr ail-dynnu,
- dileu ceisiadau dyblyg,
- gwneud y broses lwytho yn fwy amlwg.
Gadewch i ni ailddefnyddio'r data
Mewn egwyddor, mae rendrad ar ochr y gweinydd wedi'i gynllunio i ddatrys dwy broblem: peidio â dioddef o gyfyngiadau peiriannau chwilio o ran a gwella metrigau (yn anochel yn gwaethygu ). Yn y senario clasurol bod yn olaf flwyddyn (yn ôl ar Backbone.js), SSR yw'r un cais isomorphic JS rhedeg yn yr amgylchedd Node. Yn syml, mae'r gweinydd yn dychwelyd y cynllun a gynhyrchir fel ymateb i'r cais. Yna mae ailhydradu'n digwydd ar ochr y cleient, ac yna mae popeth yn gweithio heb ail-lwytho tudalennau. Ar gyfer Habr, yn yr un modd â llawer o adnoddau eraill gyda chynnwys testun, mae rendrad gweinydd yn elfen hollbwysig wrth feithrin cysylltiadau cyfeillgar â pheiriannau chwilio.
Er gwaethaf y ffaith bod mwy na chwe blynedd wedi mynd heibio ers i'r dechnoleg ymddangos, ac yn ystod yr amser hwn mae llawer o ddŵr wedi pasio o dan y bont yn y byd pen blaen, i lawer o ddatblygwyr mae'r syniad hwn yn dal i fod yn gyfrinachol. Ni wnaethom sefyll o'r neilltu a chyflwyno cais Vue gyda chefnogaeth SSR i gynhyrchu, gan golli un manylyn bach: ni wnaethom drosglwyddo'r cyflwr cychwynnol i'r cleient.
Pam? Nid oes ateb union i'r cwestiwn hwn. Naill ai nid oeddent am gynyddu maint yr ymateb gan y gweinydd, neu oherwydd criw o broblemau pensaernïol eraill, neu nid oedd yn codi. Un ffordd neu'r llall, mae taflu'r cyflwr ac ailddefnyddio popeth a wnaeth y gweinydd yn ymddangos yn eithaf priodol a defnyddiol. Mae'r dasg yn ddibwys mewn gwirionedd. i'r cyd-destun gweithredu, ac mae Vue yn ei ychwanegu'n awtomatig at y cynllun a gynhyrchir fel newidyn byd-eang: window.__INITIAL_STATE__.
Un o'r problemau sydd wedi codi yw'r anallu i drosi strwythurau cylchol yn JSON (); datryswyd hyn trwy osod strwythurau gwastad yn lle'r strwythurau hyn.
Yn ogystal, wrth ddelio â chynnwys UGC, dylech gofio y dylid trosi'r data i endidau HTML er mwyn peidio â thorri'r HTML. At y dibenion hyn rydym yn defnyddio .
Lleihau ail-drawiadau
Fel y gallwch weld o'r diagram uchod, yn ein hachos ni, mae un enghraifft Node JS yn cyflawni dwy swyddogaeth: SSR a “procsi” yn yr API, lle mae awdurdodiad defnyddiwr yn digwydd. Mae'r amgylchiad hwn yn ei gwneud hi'n amhosibl awdurdodi tra bod y cod JS yn rhedeg ar y gweinydd, gan fod y nod yn un edau, a bod y swyddogaeth SSR yn gydamserol. Hynny yw, ni all y gweinydd anfon ceisiadau ato'i hun tra bod y stack call yn brysur gyda rhywbeth. Daeth i'r amlwg ein bod wedi diweddaru'r wladwriaeth, ond ni roddodd y rhyngwyneb y gorau i blycio, gan fod yn rhaid diweddaru'r data ar y cleient gan ystyried sesiwn y defnyddiwr. Roedd angen addysgu ein cais i roi'r data cywir yn y cyflwr cychwynnol, gan ystyried mewngofnodi'r defnyddiwr.
Dim ond dau ateb oedd i’r broblem:
- cysylltu data awdurdodi â cheisiadau traws-weinydd;
- hollti haenau Node JS yn ddau achos ar wahân.
Roedd yr ateb cyntaf yn gofyn am ddefnyddio newidynnau byd-eang ar y gweinydd, ac roedd yr ail yn ymestyn y ffrâm amser ar gyfer cwblhau'r dasg o leiaf fis.
Sut i wneud dewis? Mae Habr yn aml yn symud ar hyd y llwybr â'r gwrthiant lleiaf. Yn anffurfiol, mae awydd cyffredinol i leihau'r cylch o syniad i brototeip i'r lleiafswm. Mae'r model agwedd tuag at y cynnyrch braidd yn atgoffa rhywun o'r postulates o booking.com, a'r unig wahaniaeth yw bod Habr yn cymryd adborth defnyddwyr yn llawer mwy difrifol ac yn ymddiried penderfyniadau o'r fath i chi fel datblygwr.
Yn dilyn y rhesymeg hon a fy awydd fy hun i ddatrys y broblem yn gyflym, dewisais newidynnau byd-eang. Ac, fel sy'n digwydd yn aml, mae'n rhaid i chi dalu amdanynt yn hwyr neu'n hwyrach. Fe wnaethom dalu bron ar unwaith: buom yn gweithio ar y penwythnos, yn clirio'r canlyniadau, yn ysgrifennu a dechreuodd ranu y gweinydd yn ddwy ran. Roedd y gwall yn dwp iawn, ac nid oedd y byg a oedd yn ymwneud ag ef yn hawdd i'w atgynhyrchu. Ac ydy, mae'n drueni am hyn, ond un ffordd neu'r llall, gan faglu a griddfan, serch hynny, aeth fy PoC gyda newidynnau byd-eang i mewn i gynhyrchu ac mae'n gweithio'n eithaf llwyddiannus wrth aros am symud i bensaernïaeth “dau nod”. Roedd hwn yn gam pwysig, oherwydd yn ffurfiol cyflawnwyd y nod - dysgodd SSR gyflwyno tudalen gwbl barod i'w defnyddio, a daeth yr UI yn llawer tawelach.
Rhyngwyneb Habr symudol ar ôl cam cyntaf yr ailffactorio
Yn y pen draw, mae pensaernïaeth SSR-CSR y fersiwn symudol yn arwain at y llun canlynol:
Cylched SSR-CSR “dau-nôd”. Mae API Node JS bob amser yn barod ar gyfer I / O asyncronig ac nid yw'n cael ei rwystro gan y swyddogaeth SSR, gan fod yr olaf wedi'i leoli mewn achos ar wahân. Nid oes angen cadwyn ymholiad #3.
Dileu ceisiadau dyblyg
Ar ôl i'r triniaethau gael eu perfformio, nid oedd rendrad cychwynnol y dudalen bellach yn ysgogi epilepsi. Ond roedd y defnydd pellach o Habr yn y modd SPA yn dal i achosi dryswch.
Gan mai trawsnewid y ffurflen yw sail llif y defnyddiwr rhestr o erthyglau → erthygl → sylwadau ac i'r gwrthwyneb, roedd yn bwysig gwneud y defnydd gorau o adnoddau'r gadwyn hon yn y lle cyntaf.
Mae dychwelyd i'r porthwr post yn sbarduno cais data newydd
Nid oedd angen cloddio'n ddwfn. Yn y screencast uchod gallwch weld bod y cais yn ail-ofyn am y rhestr o erthyglau wrth droi yn ôl, ac yn ystod y cais nid ydym yn gweld yr erthyglau, sy'n golygu bod y data blaenorol yn diflannu yn rhywle. Mae'n edrych fel bod y gydran rhestr erthyglau yn defnyddio gwladwriaeth leol ac yn ei golli i ddinistrio. Mewn gwirionedd, roedd y cais yn defnyddio cyflwr byd-eang, ond adeiladwyd pensaernïaeth Vuex yn uniongyrchol: mae modiwlau wedi'u clymu i dudalennau, sydd yn eu tro yn gysylltiedig â llwybrau. Ar ben hynny, mae'r holl fodiwlau yn rhai "un-amser" - mae pob ymweliad dilynol â'r dudalen yn ailysgrifennu'r modiwl cyfan:
ArticlesList: [
{ Article1 },
...
],
PageArticle: { ArticleFull1 },
Yn gyfan gwbl, roedd gennym fodiwl Rhestr Erthyglau, sy'n cynnwys gwrthrychau o fath Erthygl a modiwl Erthygl Tudalen, a oedd yn fersiwn estynedig o'r gwrthrych Erthygl, math o Erthygl Llawn. Ar y cyfan, nid yw'r gweithrediad hwn yn cario unrhyw beth ofnadwy ynddo'i hun - mae'n syml iawn, efallai y bydd rhywun hyd yn oed yn dweud naïf, ond yn hynod ddealladwy. Os byddwch chi'n ailosod y modiwl bob tro y byddwch chi'n newid y llwybr, yna gallwch chi hyd yn oed fyw gydag ef. Fodd bynnag, mae'r trawsnewidiad rhwng porthiant erthyglau, er enghraifft /porthiant → /pawb, yn sicr o daflu popeth sy'n ymwneud â'ch porthiant personol, gan mai dim ond un sydd gennym Rhestr Erthyglau, y mae angen i chi roi data newydd ynddo. Mae hyn eto yn ein harwain at ddyblygu ceisiadau.
Ar ôl casglu popeth y llwyddais i'w gloddio ar y pwnc, lluniais strwythur gwladwriaeth newydd a'i gyflwyno i'm cydweithwyr. Bu’r trafodaethau’n faith, ond yn y diwedd roedd y dadleuon o blaid yn drech na’r amheuon, a dechreuais weithredu.
Mae'n well datgelu rhesymeg penderfyniad mewn dau gam. Yn gyntaf rydym yn ceisio datgysylltu'r modiwl Vuex o'r tudalennau a'i rwymo'n uniongyrchol i'r llwybrau. Oes, bydd ychydig mwy o ddata yn y siop, bydd derbynwyr yn dod yn fwy cymhleth, ond ni fyddwn yn llwytho erthyglau ddwywaith. Ar gyfer y fersiwn symudol, efallai mai dyma'r ddadl gryfaf. Bydd yn edrych rhywbeth fel hyn:
ArticlesList: {
ROUTE_FEED: [
{ Article1 },
...
],
ROUTE_ALL: [
{ Article2 },
...
],
}
Ond beth os gall rhestrau o erthyglau orgyffwrdd rhwng llwybrau lluosog a beth os ydym am ailddefnyddio'r data gwrthrych Erthygl i rendro'r dudalen post, gan ei droi i mewn Erthygl Llawn? Yn yr achos hwn, byddai'n fwy rhesymegol defnyddio strwythur o'r fath:
ArticlesIds: {
ROUTE_FEED: [ '1', ... ],
ROUTE_ALL: [ '1', '2', ... ],
},
ArticlesList: {
'1': { Article1 },
'2': { Article2 },
...
}
Rhestr Erthyglau dim ond math o ystorfa o erthyglau yw yma. Pob erthygl a gafodd ei lawrlwytho yn ystod y sesiwn defnyddiwr. Rydym yn eu trin â’r gofal mwyaf, oherwydd dyma draffig a allai fod wedi’i lwytho yn rhywle yn y metro rhwng gorsafoedd, ac yn bendant nid ydym am achosi’r boen hon i’r defnyddiwr eto drwy ei orfodi i lwytho data y mae eisoes wedi’i lawrlwytho. . Gwrthrych ErthyglauIds yn syml, amrywiaeth o ddulliau adnabod (fel “cysylltiadau”) i wrthrychau Erthygl. Mae'r strwythur hwn yn eich galluogi i osgoi dyblygu data sy'n gyffredin i lwybrau ac ailddefnyddio'r gwrthrych Erthygl wrth rendro tudalen bost trwy gyfuno data estynedig ynddi.
Mae allbwn y rhestr o erthyglau hefyd wedi dod yn fwy tryloyw: mae'r gydran iterator yn ailadrodd trwy'r arae gydag IDau erthygl ac yn tynnu cydran ymlid yr erthygl, gan basio'r ID fel prop, ac mae'r gydran plentyn, yn ei thro, yn adfer y data angenrheidiol o Rhestr Erthyglau. Pan fyddwch chi'n mynd i'r dudalen gyhoeddi, rydyn ni'n adfer y dyddiad presennol Rhestr Erthyglau, rydym yn gwneud cais i dderbyn y data coll ac yn syml yn ei ychwanegu at y gwrthrych presennol.
Pam fod y dull hwn yn well? Fel yr ysgrifennais uchod, mae'r dull hwn yn fwy gofalus o ran data wedi'i lawrlwytho ac yn caniatáu ichi ei ailddefnyddio. Ond ar wahân i hyn, mae'n agor y ffordd i rai posibiliadau newydd sy'n ffitio'n berffaith i bensaernïaeth o'r fath. Er enghraifft, pleidleisio a llwytho erthyglau i'r porthiant wrth iddynt ymddangos. Yn syml, gallwn roi'r postiadau diweddaraf mewn “storfa” Rhestr Erthyglau, arbed rhestr ar wahân o IDs newydd yn ErthyglauIds a hysbysu'r defnyddiwr am hyn. Pan fyddwn yn clicio ar y botwm “Dangos cyhoeddiadau newydd”, yn syml, byddwn yn mewnosod IDau newydd ar ddechrau'r casgliad o'r rhestr gyfredol o erthyglau a bydd popeth yn gweithio bron yn hudolus.
Gwneud llwytho i lawr yn fwy pleserus
Yr eisin ar y gacen ailffactorio yw'r cysyniad o sgerbydau, sy'n gwneud y broses o lwytho cynnwys ar rhyngrwyd araf ychydig yn llai rhwystredig. Ni chafwyd unrhyw drafodaethau ar y mater hwn; cymerodd y llwybr o syniad i brototeip yn llythrennol ddwy awr. Tynnodd y dyluniad ei hun yn ymarferol, a dysgom ein cydrannau i wneud blociau rhannu syml, prin yn fflachio wrth aros am ddata. Yn oddrychol, mae'r dull hwn o lwytho mewn gwirionedd yn lleihau faint o hormonau straen yng nghorff y defnyddiwr. Mae'r sgerbwd yn edrych fel hyn:
Habralwytho
Yn adlewyrchu
Rydw i wedi bod yn gweithio yn Habr ers chwe mis ac mae fy ffrindiau yn dal i ofyn: wel, sut ydych chi'n ei hoffi yno? Iawn, cyfforddus - ie. Ond mae yna rywbeth sy'n gosod y swydd hon ar wahân i eraill. Gweithiais mewn timau a oedd yn gwbl ddifater am eu cynnyrch, nad oeddent yn gwybod nac yn deall pwy oedd eu defnyddwyr. Ond yma mae popeth yn wahanol. Yma rydych chi'n teimlo'n gyfrifol am yr hyn rydych chi'n ei wneud. Yn y broses o ddatblygu nodwedd, rydych chi'n dod yn berchennog yn rhannol, yn cymryd rhan ym mhob cyfarfod cynnyrch sy'n ymwneud â'ch ymarferoldeb, yn gwneud awgrymiadau ac yn gwneud penderfyniadau eich hun. Mae gwneud cynnyrch rydych chi'n ei ddefnyddio bob dydd eich hun yn cŵl iawn, ac mae ysgrifennu cod ar gyfer pobl sydd yn ôl pob tebyg yn ei ddeall yn well na chi yn deimlad anhygoel (dim coegni).
Ar ôl rhyddhau'r holl newidiadau hyn, cawsom adborth cadarnhaol, ac roedd yn braf iawn, iawn. Mae'n ysbrydoledig. Diolch! Ysgrifennwch fwy.
Gadewch imi eich atgoffa, ar ôl newidynnau byd-eang, ein bod wedi penderfynu newid y bensaernïaeth a dyrannu'r haen ddirprwy mewn enghraifft ar wahân. Mae'r bensaernïaeth “dau nod” eisoes wedi'i rhyddhau ar ffurf profion beta cyhoeddus. Nawr gall unrhyw un newid iddo a'n helpu ni i wneud Habr symudol yn well. Dyna i gyd am heddiw. Byddaf yn hapus i ateb eich holl gwestiynau yn y sylwadau.
Ffynhonnell: hab.com