RSS

Spotkanie Koła Naukowego FullStack #7: Modułowa budowa aplikacji w JavaScript

Liczba odsłon: 277

Każdy nie­try­wial­ny pro­gram mu­si zo­stać po­dzie­lo­ny na mo­du­ły funkcjo­nal­ne. Moduły te mu­szą zo­stać jed­nak po­now­nie prze­two­rzo­ne i złą­czo­ne al­bo w mo­men­cie uru­cha­mia­nia pro­gra­mu al­bo, co jest ko­rzyst­niej­sze z punk­tu wi­dze­nia wy­daj­noś­ci, w mo­men­cie przy­go­to­wy­wa­nia wer­sji prze­ka­zy­wa­nej użyt­kow­ni­kom koń­co­wym. Szczególne zna­cze­nie ma to w przy­pad­ku ję­zy­ka Java­Script. Po pierw­sze, no­we wer­sje dia­lek­tu ECMAScript mu­szą zo­stać prze­tłu­ma­czo­ne na stan­dar­do­wy Java­Script. Po dru­gie, skryp­ty mu­szą zo­stać pod­da­ne mi­ni­fi­kac­ji. Po trze­cie, ze wzglę­dów wy­daj­no­ścio­wych, klient po­wi­nien otrzy­mać je­den du­ży plik za­wie­ra­ją­cy wszyst­kie ele­men­ty (i wy­łącz­nie te ele­men­ty), któ­re są po­trzeb­ne do dzia­ła­nia apli­kac­ji.

Zagadnie­niu two­rze­nia wie­lo­mo­du­ło­wych pro­gra­mów w ję­zy­ku Java­Script zo­sta­ło po­świę­co­ne spot­ka­nie Koła Naukowego Full­Stack, któ­re mia­ło miej­sce w śro­dę 9 stycz­nia na Wydziale Auto­ma­ty­ki, Elektro­ni­ki i Informa­ty­ki Politech­ni­ki Śląskiej w Gli­wi­cach.

Spotkanie pro­wa­dził Dominik Guzy. Zaczął od wstę­pu po­ka­zu­ją­ce­go kie­ru­nek, w któ­rym roz­wi­ja się ję­zyk Java­Script, kie­dyś peł­nią­cy wy­łącz­nie ro­lę iry­tu­ją­ce­go uzu­peł­nie­nia dyna­micz­nych stron WWW. Obecnie ję­zyk ten sta­no­wi pod­sta­wę bu­do­wy peł­no­praw­nych apli­kac­ji sie­cio­wych i wśród wszyst­kich ję­zy­ków pro­gra­mo­wa­nia w ser­wi­sie Stack Overflow cie­szy się naj­więk­szą po­pu­lar­noś­cią. Zakres za­sto­so­wań obej­mu­je za­rów­no tra­dy­cyj­nie front-end, jak już i back-end, a tak­że sa­mo za­ple­cze pro­gra­mi­stycz­ne.

Kluczowym ele­men­tem te­go tak bo­ga­te­go eko­sys­te­mu jest Node.js, sil­nik Java­Script dzia­ła­ją­cy w oder­wa­niu od prze­glą­dar­ki WWW. W je­go śro­do­wis­ku dzia­ła­ją na­rzę­dzia pro­gra­mi­stycz­ne pi­sa­ne wprost w Java­Script, bio­rą­ce udział w pro­ce­sie bu­do­wa­nia apli­kac­ji. Służy on też do uru­cha­mia­nia częś­ci ser­we­ro­wej two­rzo­nych apli­kac­ji, za po­mo­cą wbu­do­wa­ne­go ser­we­ra pro­to­ko­łu HTTP.

Prelegent prze­szedł na­stęp­nie do oma­wia­nia za­sad dzia­ła­nia sil­ni­ka Java­Script. Integral­ny­mi częś­cia­mi są trans­la­tor, stos wy­wo­łań oraz ster­ta. Elementem ze­wnętrz­nym jest bi­blio­te­ka API, któ­ra udo­stęp­nia uru­cha­mia­nej apli­kac­ji funkcjo­nal­noś­ci nie­zbęd­ne do po­ro­zu­mie­wa­nia się ze świa­tem ze­wnętrz­nym. Tutaj wi­dać naj­więk­szą róż­ni­cę po­mię­dzy sil­ni­ka­mi za­szy­ty­mi w prze­glą­dar­kach WWW oraz nie­za­leż­ny­mi, ta­ki­mi jak Node.js, gdyż ofe­ru­ją róż­ne API, do­sto­so­wa­ne do śro­do­wis­ka oraz po­trzeb uru­cha­mia­nej apli­kac­ji.

Pojęciami, któ­re każ­dy pro­gra­mis­ta apli­kac­ji Node.js mu­si so­bie moc­no przy­swoić są event driven, asynchro­nous call­back oraz non-blocking. Podobnie jak w prze­glą­dar­ce WWW, apli­kac­ja ser­we­ro­wa na­pi­sa­na w ję­zy­ku Java­Script dzia­ła w jed­nym wąt­ku i re­a­gu­je na zda­rze­nia. Reakcja mu­si być jed­nak nie­blo­ku­ją­ca, by prze­twa­rza­nie jed­ne­go zda­rze­nia nie opóź­ni­ło al­bo nie za­blo­ko­wa­ło ob­słu­gi ko­lej­nych. Wszystkie od­wo­ła­nia do pli­ków, baz da­nych oraz zew­nętrz­nych ser­we­rów mu­szą być za­tem rea­li­zo­wa­ne asyn­chro­nicz­nie, z wy­ko­rzys­ta­niem obiek­tów ty­pu Promise lub słów klu­czo­wych asyncawait dia­lek­tu ES8.

Aby na­pi­sać no­wą apli­ka­cję dzia­ła­ją­cą na ser­we­rze, mu­si­my za­im­por­to­wać pew­ne stan­dar­do­we mo­du­ły bi­blio­tecz­ne. Można to zro­bić ko­rzy­sta­jąc z funk­cji re­quire, któ­rej ar­gu­men­tem jest naz­wa włą­cza­ne­go mo­du­łu. W ten spo­sób mo­że­my użyć mo­du­łu http, któ­ry po­zwa­la za­re­jes­tro­wać punk­ty koń­co­we REST i uru­cho­mić ser­wer HTTP ob­słu­gu­ją­cy żą­da­nia wy­sy­ła­ne pod te punk­ty, lub mo­du­łu express z bi­blio­te­ki ExpressJS, któ­ry po­zwa­la zro­bić to sa­mo za po­mo­cą krót­sze­go i bar­dziej czy­tel­ne­go ko­du. Poszczegól­ne mo­du­ły bi­blio­tecz­ne do­da­je­my do pro­jek­tu za po­mo­cą apli­kac­ji npm lub yarn, na szczęś­cie ko­rzy­sta­ją­cych z tych sa­mych re­po­zy­to­riów oraz te­go sa­me­go for­ma­tu opi­su apli­kac­ji. Korzystamy z nich rów­nież, by uru­cho­mić NodeJS i na­szą apli­ka­cję. Możemy też so­bie zna­czą­co ułat­wić ży­cie i sko­rzys­tać z na­rzę­dzia Nodemon, któ­re auto­ma­tycz­nie uru­cha­mia po­now­nie apli­ka­cję w mo­men­cie wy­kry­cia zmian w pli­kach źród­ło­wych.

W pew­nym mo­men­cie ko­rzy­sta­nie z go­to­wych mo­du­łów bi­blio­tecz­nych prze­sta­je jed­nak wy­star­czać i trze­ba za­cząć two­rzyć włas­ne. Tutaj przy­da­je się moż­li­wość trans­lac­ji tek­stu źród­ło­we­go pro­gra­mu za po­mo­cą na­rzę­dzi two­rzą­cych śro­do­wis­ko pro­gra­mi­stycz­ne NodeJS. Babel do­ko­nu­je trans­pi­lac­ji, czy­li trans­lac­ji tek­stu źród­ło­we­go ECMAScript do wska­za­ne­go dia­lek­tu Java­Script, dzię­ki cze­mu nasz pro­gram mo­że zo­stać uru­cho­mio­ny nie tyl­ko w naj­now­szych prze­glą­dar­kach WWW, ale też w ra­mach Micro­soft Inter­net Explo­rer, a tak­że w star­szych wer­sjach śro­do­wis­ka NodeJS. Z kolei Webpack nad­zo­ru­je prze­twa­rza­nie i sca­la­nie pli­ków źród­ło­wych, dzię­ki cze­mu mo­że­my do­star­czać apli­ka­cję w po­sta­ci nie se­tek ma­łych pli­ków mo­zol­nie wczy­ty­wa­nych przez prze­glą­dar­kę, lecz kil­ku du­żych za­so­bów po­bie­ra­nych w ra­mach po­je­dyn­czych, rów­no­leg­łych żą­dań HTTP.

Prezenta­cja każ­de­go roz­wią­za­nia lub na­rzę­dzia by­ła uzu­peł­nio­na de­mon­strac­ją „na ży­wo”. Prelegent za po­mo­cą na­rzę­dzia yarn stwo­rzył no­wą apli­ka­cję, do­dał do pro­jek­tu wy­ma­ga­ne bi­blio­te­ki ze­wnętrz­ne, za­pro­gra­mo­wał bar­dzo pros­tą apli­ka­cję ser­we­ro­wą i uru­cho­mił ją, po­ka­zu­jąc wy­ni­ki w prze­glą­dar­ce. Następ­nie za­de­mon­stro­wał moż­li­wość auto­ma­tycz­ne­go aktua­li­zo­wa­nia apli­kac­ji po do­ko­na­niu zmian w jej tekś­cie źród­ło­wym i po­rów­nał ten tekst z wy­ni­kiem trans­pi­lac­ji. Nie uda­ła się je­dy­nie pre­zen­tac­ja na­rzę­dzia Webpack, któ­re nie chcia­ło współ­pra­co­wać z bi­blio­te­ką ExpressJS, praw­do­po­dob­nie z po­wo­du zna­ne­go błę­du na­rzę­dzia.

Prezenta­cja świet­nie wpro­wa­dza­ła w pod­sta­wo­we za­gad­nie­nia zwią­za­ne z two­rze­niem no­wej apli­kac­ji dzia­ła­ją­cej po stro­nie ser­we­ra, zbu­do­wa­nej z wy­ko­rzys­ta­niem go­to­wych mo­du­łów zew­nętrz­nych, ale też włas­nych mo­du­łów funkcjo­nal­nych. Szkoda, że ten ostat­ni as­pekt nie zo­stał moc­niej pod­kreś­lo­ny, w zgo­dzie z te­ma­tem wy­stą­pie­nia. Przyjęta treść pre­zen­tac­ji by­ła jed­nak ideal­na, by prze­ła­mać w po­cząt­ku­ją­cych lęk przed sto­pniem skom­pli­ko­wa­nia śro­do­wis­ka NodeJS i za­chę­cić ich do two­rze­nia włas­nych apli­kac­ji.

Warto też pod­kre­ślić świet­ną or­ga­ni­za­cję zda­rze­nia, któ­re za­czę­ło się i skoń­czy­ło pra­wie ideal­nie o cza­sie i by­ło po­zba­wio­ne ja­kich­kol­wiek prob­le­mów tech­nicz­nych.

Organiza­to­rzy za­po­wie­dzie­li, że śro­do­we spot­ka­nie by­ło ostat­nim w ra­mach koń­czą­ce­go się se­me­stru. Cykl spot­kań Koła Naukowego Full­Stack zo­sta­nie wzno­wio­ny naj­praw­do­po­dob­niej na po­cząt­ku mar­ca. Gorąco za­chę­cam za­tem, aby za­pi­sać się do gru­py Koła w ser­wi­sie Meetup.com i cze­kać na po­wia­do­mie­nia.