RSS

Statyczne HTML: przeżytek i przyszłość zarazem

Liczba odsłon: 264

Pierwsze stro­ny WWW po­wsta­wa­ły ja­ko sta­tycz­ne zbio­ry HTML. Ich wy­gląd nie był istot­ny: wcze­sne wer­sje prze­glą­da­rek nie po­tra­fi­ły ry­so­wać obra­zów ani ta­bel, więc stro­ny skła­da­ły się wy­łącz­nie z aka­pi­tów tek­stu za­wie­ra­ją­ce­go od­noś­ni­ki.

Postęp szyb­ko spo­wo­do­wał uroz­maice­nie wy­glą­du stron w Sieci. Kolejne wer­sje stan­dar­du HTML wpro­wa­dzi­ły wy­bór czcio­nek i ko­lo­rów, za­miesz­cza­nie obra­zów oraz two­rze­nie skom­pli­ko­wa­nych ukła­dów stron. Modny przez chwi­lę stan­dard DHTML do­dat­ko­wo umoż­li­wiał two­rze­nie in­ter­ak­tyw­nych warstw i obiek­tów, a apli­kac­je sie­cio­we za­częły zbli­żać się wy­glą­dem i funkcjo­nal­noś­cią do opro­gra­mo­wa­nia na­tyw­ne­go. Stworze­nie du­że­go, jed­no­li­te­go gra­ficz­nie i fun­kcjo­nal­nie ser­wi­su WWW wciąż jed­nak by­ło po­waż­nym za­da­niem, wy­ma­ga­ją­cym uży­cia skom­pli­ko­wa­nych na­rzę­dzi.

Najpierw za­czę­to sto­so­wać ge­ne­ra­to­ry ser­wi­sów WWW. Pozwa­la­ły one bu­do­wać stro­ny z nie­za­leż­nych frag­men­tów, łą­czo­nych w ca­łość w mo­men­cie publi­ko­wa­nia ser­wi­su. Na stro­nach moż­na by­ło rów­nież osa­dzać włas­ne skryp­ty, wy­ko­ny­wa­ne w mo­men­cie łą­cze­nia. W ten spo­sób po­wsta­ły pierw­sze sys­te­my do­bie­ra­nia re­klam na stro­nach WWW: przy każ­dym wdro­że­niu na każ­dej stro­nie umiesz­cza­na by­ła in­na re­kla­ma, by za­pew­nić względ­nie rów­no­mier­ną licz­bę od­słon każ­dej z nich.

Prawdzi­wa re­wo­lu­cja na­de­szła jed­nak w mo­men­cie, gdy po­ja­wi­ły się ję­zy­ki pro­gra­mo­wa­nia umoż­li­wia­ją­ce dyna­micz­ne ge­ne­ro­wa­nie treś­ci prze­sy­ła­nej klien­tom. Zamiast eks­pe­ry­men­to­wać z nie­wy­god­ny­mi, trud­ny­mi do na­pi­sa­nia skryp­ta­mi CGI, moż­na by­ło za­pi­sać pro­gram ASP lub JSP i uzys­kać w peł­ni in­ter­ak­tyw­ną apli­ka­cję sie­cio­wą. Największy wpływ miał ję­zyk PHP, któ­ry w po­łą­cze­niu z in­ny­mi dar­mo­wy­mi pro­duk­ta­mi – ser­we­rem Apache HTTPD oraz ba­zą da­nych MySQL – two­rzył plat­for­mę umoż­li­wia­ją­cą każ­de­mu ama­to­ro­wi stwo­rze­nie funkcjo­nal­nej apli­kac­ji inter­ne­to­wej.

Nic dziw­ne­go za­tem, że ję­zyk PHP za­czął być sze­ro­ko sto­so­wa­ny w za­sto­so­wa­niach ama­tors­kich i ko­mer­cyj­nych. Przez la­ta roz­wi­jał się, z pros­te­go ję­zy­ka skryp­to­we­go prze­ista­cza­jąc się w peł­no­praw­ny, obiek­to­wy ję­zyk pro­gra­mo­wa­nia. Choć na pew­no nie jest po­zba­wio­ny wad i łat­wy do opa­no­wa­nia, z pew­ny­mi roz­sze­rze­nia­mi ko­rzy­sta­ją z nie­go na­wet ta­cy gi­gan­ci, jak Facebook.


Trzy naj­waż­niej­sze za­le­ty wy­ni­ka­ją­ce ze sto­so­wa­nia dyna­micz­nych stron WWW to:

Dzisiaj te prob­le­my moż­na roz­wią­zać w in­ny spo­sób. Wykorzy­sta­nie wspól­ne­go mo­ty­wu gra­ficz­ne­go i skła­da­nie ko­du stro­ny z nie­za­leż­nych, łą­czo­nych ze so­bą frag­men­tów to coś, z czym świet­nie ra­dzą so­bie sta­tycz­ne ge­ne­ra­to­ry ser­wi­sów WWW. Oszczędność miej­sca też nie jest już za­le­tą: ty­po­wy ser­wer mo­że w ra­zie po­trze­by zmieś­cić kod wszyst­kich stron ser­wi­su na­wet w pa­mię­ci opera­cyj­nej.

Większość twór­ców ser­wi­sów inter­ne­to­wych wciąż ko­rzy­sta z na­rzę­dzi w sty­lu PHP z ostat­nie­go z wy­mie­nio­nych po­wo­dów: by ge­ne­ro­wać treść na pod­sta­wie za­war­toś­ci ba­zy da­nych. Obecnie jest to nie­zbęd­ne w za­sa­dzie w każ­dym ser­wi­sie WWW: skle­pie inter­ne­to­wym, ser­wi­sie in­tra­ne­to­wym lub blo­gu.

Czy jed­nak trze­ba to ro­bić za po­mo­cą roz­wią­zań ta­kich jak PHP? Przecież sa­ma stro­na za­wie­ra­ją­ca dyna­micz­ne da­ne mo­że być wy­ge­ne­ro­wa­na sta­tycz­nie. To, co dyna­micz­ne, moż­na do­ło­żyć póź­niej za po­mo­cą roz­wią­zań ta­kich jak AJAXREST. Wymaga to więk­sze­go na­kła­du pra­cy ze stro­ny pro­gra­mis­ty, jed­nak efek­tem jest ele­ganc­kie roz­wią­za­nie, oszczę­dza­ją­ce prze­pus­to­wość łącz ser­we­ra i klienta.

Owszem, dyna­micz­ne frag­men­ty stro­ny mu­szą zo­stać prze­kształ­co­ne na po­stać HTML lub JSON przez pro­gram dzia­ła­ją­cy po stro­nie ser­we­ra. Na dzień dzi­siej­szy nie ma za­tem łat­wej uciecz­ki przez roz­wią­za­nia­mi w sty­lu PHP, moż­na tyl­ko ogra­ni­czyć po­trze­bę ich sto­so­wa­nia. Istnieją już jed­nak roz­wią­za­nia ba­zo­da­no­we, umoż­li­wia­ją­ce prze­ka­zy­wa­nie wy­ni­ków w po­sta­ci struk­tur JSON, któ­re moż­na od ra­zu wy­ko­rzys­tać do za­peł­nia­nia stro­ny. W ten spo­sób dyna­micz­nym ge­ne­ra­to­rem ko­du sta­ją się po częś­ci ba­za da­nych oraz włas­ny kod Java­Script.


Zmiana spo­so­bu ge­ne­ro­wa­nia treś­ci du­że­go ser­wi­su WWW z dyna­micz­ne­go na sta­tycz­ny to na­praw­dę po­waż­na pra­ca. Warto ją pod­jąć tyl­ko wte­dy, gdy jest op­ła­cal­na i nie stra­ci się moż­li­woś­ci, któ­re są nie­zbęd­ne do dzia­ła­nia ser­wi­su.

Zacznijmy od wad. Przede wszyst­kim, trze­ba użyć do­dat­ko­we­go na­rzę­dzia, umoż­li­wia­ją­ce­go sta­tycz­ne ge­ne­ro­wa­nie stro­ny: al­bo spe­cja­li­zo­wa­ne­go, roz­bu­do­wa­ne­go, al­bo pros­te­go, skro­jo­ne­go do po­trzeb. Struktura ser­wi­su mu­si zo­stać do­sto­so­wa­na do te­go na­rzę­dzia, co mo­że ozna­czać re­zyg­na­cję z nie­któ­rych wzor­ców pro­jek­to­wych, na przy­kład cen­tral­ne­go ste­row­ni­ka ser­wi­su.

Kolejne prze­kształ­ce­nie mu­si po­le­gać na wpro­wa­dze­niu me­cha­niz­mu REST. Po pierw­sze, ser­wer mu­si udo­stęp­niać od­po­wied­ni inter­fejs, któ­ry trze­ba za­pro­jek­to­wać, zreali­zo­wać i prze­te­sto­wać. Następ­nie z ko­du stro­ny trze­ba usu­nąć dyna­micz­nie ge­ne­ro­wa­ne frag­men­ty i za­stą­pić je skryp­ta­mi Java­Script wczy­tu­ją­cy­mi da­ne po­przez AJAXREST.

Jakich zy­sków mo­że­my ocze­ki­wać po tak cięż­kiej pra­cy? Przede wszyst­kim mniej­sze­go ob­cią­że­nia ser­we­ra i szyb­sze­go wczy­ty­wa­nia się stron. Spora część ser­wi­su nag­le sta­nie się zwyk­ły­mi, sta­tycz­ny­mi zbio­ra­mi HTML, co zlik­wi­du­je ko­niecz­ność uru­cha­mia­nia ge­ne­ru­ją­ce­go je inter­pre­te­ra i umoż­li­wi wy­ko­rzys­ta­nie me­cha­niz­mu send­file() słu­żą­ce­go do bez­po­śred­nie­go skie­ro­wa­nia zbio­ru dy­sko­we­go do gniaz­da sie­cio­we­go. Ponadto, bu­fo­ro­wa­nie wy­ni­ków dzia­ła­nia inter­fej­su REST bę­dzie łat­wiej­sze niż bu­fo­ro­wa­nie peł­nych stron WWW.

Poprawie mo­że też ulec bez­pie­czeń­stwo ser­wi­su. Wysiłek zwią­za­ny z za­bez­pie­cza­niem i te­sto­wa­niem bę­dzie moż­na sku­pić na in­ter­fej­sie REST udo­stęp­nia­ją­cym da­ne, za­miast roz­pra­szać go po wszyst­kich stro­nach ser­wi­su. Statyczne zbio­ry HTML są ideal­ne z punk­tu wi­dze­nia bez­pie­czeń­stwa: w za­sa­dzie nie da się do nich wła­mać (po­mi­ja­jąc ewen­tu­al­ne błę­dy opro­gra­mo­wa­nia ser­we­ra).


Statyczne ser­wi­sy WWW nie są na­rzę­dziem właś­ci­wym dla każ­de­go. Jeszcze nie­daw­no by­ły uwa­ża­ne za re­likt mi­nio­nej epo­ki, właś­ci­wy tyl­ko dla po­cząt­ku­ją­cych ama­to­rów. Pojawie­nie się no­wych na­rzę­dzi i tech­nik przy­wró­ci­ło im daw­ny blask i umoż­li­wi­ło reali­zo­wa­nie za ich po­mo­cą wszyst­kie­go, co po­tra­fią zro­bić ser­wi­sy dyna­micz­ne — tyl­ko z więk­szą wy­daj­noś­cią.

W cią­gu kil­ku ostat­nich mie­się­cy już kil­ka ra­zy spot­ka­łem się z przy­pad­ka­mi mi­grac­ji dyna­micz­nie ge­ne­ro­wa­nych blo­gów (naj­częś­ciej bu­do­wa­nych z wy­ko­rzys­ta­niem plat­for­my Word­Press) do po­sta­ci sta­tycz­nej. Kto wie, mo­że sam za­sta­no­wię się nad ta­ką moż­li­woś­cią? Pierwszy krok już uczy­ni­łem: licz­nik od­wie­dzin, któ­ry wi­dać w le­wym dol­ny ro­gu stro­ny, jest od­ręb­nym ele­men­tem, ge­ne­ro­wa­nym przez skrypt Java­Script na pod­sta­wie bu­fo­ro­wa­ne­go RESTowego źród­ła da­nych.