Blog

Budujemy prostą stronę na bazie Express.js Cz I

Krótki tutorial budowy prostej strony przy pomocy Express.js. Odsłona pierwsza.

Budujemy prostą stronę na bazie Express.js Cz I

Patrząc na tytuł dzisiejszego wpisu można odnieść wrażenie – zwłaszcza w kontekście moich niedawnych zachwytów nad walorami Nuxt.js – że do czynienia mamy tutaj ze swoistego rodzaju regresem w zakresie omawianej problematyki i już tylko należy wypatrywać na horyzoncie tekstów o jQuery UI, a potem kto wie czy nie będzie można poczytać o Flashu. Oczywiście do pewnego stopnia byłbym skłonny z taką oceną (o pewnym uwstecznieniu) się zgodzić, ale jak zawsze w takich okolicznościach wyłącznie pod pewnymi zastrzeżeniami. Otóż w przypadku aplikacji internetowych bez wątpienia od kilku lat zaobserwować można tendencję do przesuwania coraz większej części logiki działania takich rozwiązań na stronę klienta. Oczywiście nic nie stoi na przeszkodzie, by na bazie Expressa jak najbardziej da się zbudować aplikację typu SPA, ale ważniejszym jest tutaj fakt, że na ten moment trudno sobie wyobrazić alternatywę dla pewnych tradycyjnych zadań realizowanych po stronie serwera, jak chociażby przechowywanie danych czy – przynajmniej do pewnego stopnia – mechanizmów autoryzacji użytkownika.

Z resztą co by wiele nie mówić czy pisać wystarczy przywołać fakt, że bohater kilku najbliższych wpisów, czyli Express.js to chyba najczęściej pobierany pakiety dla środowiska Node.js. Na początku tego roku – po świątecznej zadyszce – powoli wraca do normalnego poziomu z wynikiem prawie 14 milionów pobrań tygodniowo. Dla porównania React w tym samym okresie osiągnął wynik niewiele przekraczający 8 milionów. Natomiast w mojej opinii do budowy prosty witryn internetowych, a tylko takie pozostają w obrębie moich zainteresowań, istnieją lepsze czy też bardziej przyjazne rozwiązania. Właśnie omawiany przeze mnie niedawno Nuxt jest tego doskonałym przykładem.

Jednakże – o czym wspominałem w debiutanckim wpisie – do całkiem niedawna nie miałem bladego pojęcia, że można inaczej podejść do tworzenia aplikacji internetowej, czyli bez umieszczania praktycznie całości jej biznesowej logiki po stronie back-endu. Był to efekt tyleż absolutnej ignorancji, wynikającej z raczej powierzchownego zainteresowania web developmentem, co rezultat dotychczasowych doświadczeń. Jako osoba mocno do Pythona przyspawana rzecz jasna eksperymentowałem z jednym z najgorętszych frameworków, które powstało dla mojego ulubionego języka programowania, czyli Django, który chociażby ze względów metrykalnych reprezentuje tradycyjne podejście do budowania rozwiązań webowych. Próby te trudno uznać za przesadnie udane, ale przy okazji siłą rzeczy parę podstawowych informacji i pojęć na temat wzorca MVC (Model-View-Controller) przyswoiłem. Na marginesie zaznaczyć należy, że twórcy Django wolą mówić w przypadku swojego rozwiązania o MTV, czyli Model-Template-View z powodu pewnych subtelnych różnic, których piszący te słowa nie ogarnia. Tym niemniej mimo faktycznej czy też mocno nadmuchanej różnicy “architektonicznej”, ale z grubsza zasada pozostaje w mocy, czyli na serwery trafia request w postaci odpowiednio spreparowanego adresu url, który zgodnie z zaplanowaną logiką jest następnie obsłużony.

W związku z tymi doświadczeniami podejmując decyzję o wejściu z przytupem do swobodnego pisania w Internetach w naturalny sposób podążyłem właśnie tą wcześniej zapoznaną ścieżką, czyli wpierw zacząłem od przeglądu dostępnych CMS-ów oraz frameworków back-endowych. Rzecz jasna w tym ostatnim przypadku – jeśli chodzi o Node.js – lider jest dość jednoznaczny, czyli bohater serii tego i najbliższych kilku wpisów. 

I tutaj pierwsze zaskoczenie przyszło dość szybko, a właściwie od razu. Otóż na bazie nadmienionych przygód z Django na długi czas zostało ukształtowane moje wyobrażenie typowego frameworka webowego, jako tworu przeładowanego funkcjonalnościami, a przy tym charakteryzującego się dość sztywno ustalonym schematem dochodzenia do finalnego efektu. Oczywiście przy całej swojej ignorancji dopuszczam do siebie myśl, że taka ocena przymiotów Django może być wyjątkowo krzywdząca i problemem nie jest samo narzędzie jeno niekompetentny użytkownik, który niewłaściwie dobierał narzędzia do zakładanych celów. Tym niemniej Express.js jest w mojej opinii znakomitym przykładem tego, że czasem mniej znaczy więcej, ponieważ jego działanie de facto sprowadza się do przyjęcia żądania HTTP od klienta i w efekcie zwrócenia odpowiedzi. To co się wydarza między tymi dwoma momentami zależy już od fantazji twórcy, który nie tylko nie jest krępowany narzuconymi ramami, ale wręcz zmuszony jest dokonać decyzji, z jakich szeroko dostępnych narzędzi skorzystać, bądź też pisać wszystko od zera. Oczywiście takie podejście ma tak plusy dodatnie jak i ujemne, ale z całą pewnością dzięki temu próg wejścia wydaje się być relatywnie niski. Mimo najszczerszych chęci i kilkudziesięciu godzin spędzonych z Django nie miałem pewności,czy potrafiłbym samodzielnie wyjść poza zakres przerabianych przykładów, a już z pewnością bez ciągłego zaglądania do dokumentacji czy różnej maści ściągawek. W przypadku ekosystemu Node.js po jednym niezbyt intensywnym weekendzie wyprodukowałem niezbyt urodziwą witrynę blogową, która pobierała dynamiczne treści via API z jednego sieciowych CMS-ów, ale co ważniejsze: na koniec czułem – mimo że obficie korzystałem z różnych poradników – że oto stworzyłem coś własnego, zaś w przypadku Django non stop towarzyszyło mi przemożne uczucie alienacji.
Myślę, że najlepiej tę różnicę pokazać na przykładzie i temu w pierwszym rzędzie ma służyć ten kilkuczęściowy przewodnik, który jednak nie będzie żadną miarą rodzajem wprowadzenia do platformy Express.js. Po pierwsze, nie czuję się – w sposób nawet jak na mnie wyjątkowy – osobą kompetentną do tego zadania, a ukrywanie swoich praktycznych braków za pomocą przepisywania dokumentacji zupełnie mnie nie bawi. Natomiast ważniejszy jest tutaj chat, że w projekcie prostej strony internetowej, który opisany zostanie w dwóch kolejnych – tak przynajmniej zakładam – odsłonach, ten framework służy “tylko” jako swoiste spoiwo dla różnorodnych narzędzi, które do tego celu zostaną wykorzystane. Dlatego warto już na sam koniec słów parę napisać, co będziemy budować przez kilka kolejnych wpisów, a będzie to prosta strona blogowa, jednak zbudowana w sposób nie do końca klasyczny, ponieważ spora część tradycyjnie back-endowych zadań zostanie oddelegowana na zewnętrzne rozwiązanie. Chodzi mianowicie o system do zarządzania treścią, który nie będzie sam w sobie częścią projektu, ponieważ do tego celu (tworzenia kontentu) wykorzystana zostanie webowa odsłona jednego z tak zwanych “bezgłowych” CMS-ów (headless CMS). Kandydatów do tej roli mam trzech, czyli tyle ile usług, dla których w swoim czasie założyłem konto, ale prawdopodobnie będzie to usługa dostępna za pośrednictwem witryny https://prismic.io/, jako najlepiej mi znana, choć mimo to nadal bardzo słabo i stąd brak ostatecznej decyzji kierunkowej w tym zakresie. Zawartość wpisów blogowych pobierana będzie za pośrednictwem dostępnego API i to właśnie ten kanał wymiany komunikacji będzie de facto częścią projektu a nie sam webowy CMS, którego specjalnie omawiać nie zamierzam, choć może kiedyś poświęcę temu osobny tekst, Zaś do prezentacji tak pozyskanych danych użyjemy silnik czy tam system szablonów, jedyny z którym czuję się jakoś w miarę komfortowo, czyli Handlebars. Całość zaś – jak wspominałem wcześniej – będzie oparta na Express.js.