Jaunā mājaslapa: ardievu, WordPress - sveiks, Eleventy
Apmēram 10 gadus mana mājaslapa strādāja WordPress sistēmā. Tā ir ļoti ērta vide, un katru gadu kļūst aizvien ērtāka. Tomēr pagājušonedēļ no tās atvadījos, un pārcēlu visus rakstus citur. Tam bija 3 iemesli: drošība, ātrdarbība un uzticamība. Pie reizes arī atjaunoju dizainu. Īsi aprakstīšu, ko izvēlējos vietā, un varbūt kādu pamudināšu rīkoties līdzīgi.
WordPress ir pasaulē populārākais satura pārvaldnieks: to lieto vairāk kā 43% visu mājaslapu. Ņemot vērā šo popularitāti, nav brīnums, ka WordPress ir arī viena no uzlauztākajām platformām pasaulē, tāpēc ir svarīgi to regulāri atjaunot. Lielākā daļa ievainojamību gan nāk no izmantotajiem spraudņiem, tāpēc tos arī vajag regulāri atjaunot. Tas viss prasa laiku un ir kā krievu rulete, jo nekad nevar zināt, vai kaut ko atjaunojot, nekas lapā nesaplīsīs un nepārbīdīsies (un tad atkal ir jātērē laiks, labojot). Mana lapa lietoja 25 dažādus spraudņus. Daļa spraudņu bija domāta, lai samazinātu ielādējamo failu skaitu, taču neskatoties ne uz ko (un gan jau es kaut ko nemāku), šī lapa lādēja 49 dažādus failus un “svera” pusmegabaitu saspiestā veidā.
Tā kā manā lapā nav nekādu interaktīvo elementu, vai vispār jebkā tāda, ko vajadzētu mainīt katram apmeklētājam (pat komentāriem biju izmantojis atsevišķu ārējo pakalpojumu - Disqus), vai tiešām nevar labāk?
Dažus gadus atpakaļ tīmekļa izstrādē sāka kļūt populāra jauna arhitektūra, ko sauc par Jamstack. Tās pamatideja ir, ka viss, ko ir iespējams noģenerēt vienreiz (statiski), tiek ģenerēts, bet jebkādi mainīgie (dinamiskie) elementi tiek veidoti ar JavaScript palīdzību. Tas nenozīmē, ka tīmekļa izstrāde atgriezās senajos laikos, kad lapas rakstīja HTML redaktoros un sūtīja uz serveriem ar FTP, ne arī to, ka, ka vietnes kļūst statiskas un nemainīgas. Tieši otrādi.
Par piemēru var minēt kaut vai Twitter lapu, kas arī sastāv no statiskiem elementiem (dizains, izkārtojums), bet viss vajadzīgais saturs un visas izmaiņas tajā tiek ievietotas ar JavaScript palīdzību. Jamstack arhitektūrā dizains un izkārtojums arī tiek maksimāli “atkabināti” no satura, un arī tas nav nekas jauns - te par piemēru var minēt Wikipedia, kur visi šķirkļi un citas lapas tiek rakstītas īpašajā (samērā primitīvajā, un tāpēc viegli saprotamajā jebkuram cilvēkam) valodā, ko sistēma vēlāk pārveido skaistajās enciklopēdijas lapās. Jamstack arhitektūrā šī loma ir atvēlēta valodai Markdown. Autoriem, protams, nav obligāti jāsaprot un jāraksta šajā valodā, jo ir arī ļoti daudz rīku, kā to rakstīt grafiskajā vidē (WYSIWYG jeb kas līdzīgs tam pašam WordPress).
Tas, ka saturs kļūst par statiskajām lapām, nozīmē, ka serverim nav jāuztur kāda speciāla programmatūra un jāapstrādā desmitiem datubāžu pieprasījumu katru reizi, kad vietni kāds apmeklē. Lapas ielādējas zibenīgi, bet potenciālajam uzbrucējam zūd lielākā daļa lietu, ko viņš varētu uzlauzt. Šīs lapas pārsvarā tiek glabātas satura piegādes tīklā (CDN), tāpēc tādām lapām kā mana arī serveri vairs nav nepieciešams uzturēt: tās augšupielādē CDN sistēmā un aizmirst, un tad CDN rūpējas gan par drošību, gan par satura pieejamību. Mana lapa arī nepazūd, ja kas notiek ar manu serveri, vai ar datucentru, kur tas fiziski atrodas. Tas arī nozīmē, ka lapas atrodas iespējami tuvu pašiem apmeklētājiem, tādējādi nodrošinot maksimāli ātru lapas ielādi. Es izvēlējos turēt savu mājaslapu sistēmā Cloudflare Pages, kas, papildu visiem iepriekšējiem apsvērumiem, ir arī bez maksas.
Kur tad mēs tos dizaina un satura failus glabāsim? Ja vienīgā kopija būtu izstrādātāja datorā, mājaslapas izstrādē nebūtu iespējas piedalīties vairākiem cilvēkiem, nemaz nerunājot par to, ka izstrādātāja dators var salūzt. Gadu desmitiem programmētāji izmanto versiju vadības sistēmas. Tās nodrošina centralizētu failu glabāšanu un piekļuvi tiem. To pārsvarā lieto teksta failiem (tādiem kā programmatūras pirmkods), un katram tiek glabāts izmaiņu žurnāls, tādējādi apkopojot, kas, kad un kāpēc ir veicis kādas izmaiņas tajos. Nekāda moderna programmatūras izstrāde bez versiju vadības sistēmas nav iedomājama, pat ja projekts ir mazs un pie tā strādā tikai viens programmētājs, jo nodrošina izmaiņu pārskatāmību, kā arī iespēju “attīt” versijas atpakaļ (atgriezt failus tādā stāvokli, kādā tie bija jebkurā no pagātnes versijām, vai pat izvēlēties kuras no izmaiņām par šo laiku paturēt un kuras - nē), ja jaunākas izmaiņas kaut ko salauza. Šāda failu pārvaldība ir arī izcili piemērota citiem teksta failiem: grāmatām, žurnāliem, un arī tīmekļa lapām. Tādas sistēmas kā GitHub un GitLab ļauj glabāt datus savos serveros. Turklāt, lielākajai daļai mājaslapu pilnīgi pietiks ar funkcionalitāti, ko tās nodrošina bez maksas. Tātad, savus serverus uzturēt nav nepieciešams arī tam.
Jamstack realizē dažādi ģeneratori. Viens no senākajiem ir Jekyll, kas parādījās 2008. gadā, kad pat pats Jamstack termins vēl nebija izgudrots. Kā populārākos, vēl var minēt Gatsby, Hugo un Next.js. Es izvēlējos nedaudz mazāk zināmu - Eleventy, kura galvenā priekšrocība (vai, dažiem, trūkums) ir vienkāršība: tas nav pārbāzts ar funkcionalitāti, bet tas arī nemēģina mani ierobežot ar kaut kādām savām idejām par to, kā man ir labāk strādāt. Piemēram, tas nespiež mani izmantot kādu JavaScript satvaru (vai vispār izmantot JavaScript manā lapā). Tas dara to, ko es vēlos, tieši tā, kā es to vēlos. Viena no zināmākajām vietnēm, kas izmanto Eleventy, laikam ir Foursquare.
Ja mēs glabājam mākonī gan saturu, gan ģenerētās lapas, kur ir vislabāk tās lapas ģenerēt? Protams, ka mākonī! Cloudflare Pages var sasaistīt ar GitHub vai GitLab kontu un ļaut tam parūpēties par visu: tiklīdz kādas izmaiņas tiek veiktas, Cloudflare noģenerē lapas no jauna un nopublicē tās savā tīklā. Tiek glabātas arī iepriekšējās versijas, tāpēc, ja kaut kas saplīst, var acumirklī atgriezt kādu vecāku mājaslapas versiju, nepārbūvējot to no jauna caur versiju vadības sistēmu.
Kopumā mana pieredze ar Eleventy un moderniem izvēršanas rīkiem ir bijusi interesanta un pozitīva. Lapa strādā ātrāk, ir krietni mazāka pēc apjoma un ielādē gandrīz uz pusi mazāk failu.