A webfejlesztés művészete – egyedi vagy CMS?

Gyakran felmerülő kérdés, hogy egy tervezett vagy éppen átköltöztetésre érett webhelyet, legyen az bármilyen formátumú is, milyen módon érdemes megvalósítani. Valóban egyedi megvalósításokra már ritkábban van szükség, mégsincs konszenzus azzal kapcsolatban, hogy melyik a legideálisabb megoldás a legfontosabb szempontok, azaz a könnyű kezelhetőség, a stabilitás, a biztonság és a költséghatékonyság szempontjából. A korszerűbbnél korszerűbb freemium dobozos megoldások mellett a webfejlesztés olyan művészet, ami közben megértjük a web lelki világát. Ezért is érdemes webfejlesztést tanulni, de most inkább a webhelyeknek otthont adó infrastruktúráról lesz szó.

Ha webhelyről van szó, rég természetesnek vesszük, hogy dinamikus webhelyről beszélünk, az pedig teljesen feladatfüggő, hogy mennyire fontos a reszponzív jelleg, már-már művészi kialakítás a megjelenítés szempontjából.

10-15 évvel ezelőtt az első, nagy teljesítményű, de bármi számára könnyen telepíthető tartalomkezelő rendszerek (CMS) elterjedésével teljesen megváltozott a világ. Igaz, többen vannak, akik saját blogmotort írnak. Még ha egészen profi fejlesztésről is van szó, könnyen lehet, hogy előbb vagy utóbb, de sokkal több időt kell majd fordítani rá, mint egy nagyon alaposan dokumentált, széles community supporttal vagy dedikált supporttal rendelkező rendszer esetén, ahogy azt sem nehéz belátni, hogy alighanem senki sem tud egyedül a leglényegesebb szempontok tekintetében jobb blogmotort fejleszteni, mint egy több száz fejlesztőből álló fejlesztőcsapat, amelyik főállásban fejleszti valamelyik jól ismert CMS-t, ami több millió, legkülönfélébb webhely lelkét jelenti.

Ha tartalomkezelő rendszerről van szó, nagyon sokaknak a WordPress jut eszébe, ami egyáltalán nem biztos, hogy olyan remek választás. Főleg, ha valaki saját helyen szeretné telepíteni és üzemeltetni.

A csupasz WP önmagában egy biztonságos CMS, viszont a felhasználó előbb vagy utóbb, de úgyis a több tízezer, mások által írt plugin közül telepít majd néhányat, valamilyen kényelmi funkció miatt. Ezek pedig  egyrészt hatalmasra növelhetik az oldal feltörésének kockázatát, mivel a WP core ugyan rendszeresen frissíti önmagát, a plugin a CMS alapjától független életet él, esetleg évekig nem adnak ki hozzá frissítést. A CMS-ek feltörésének szinte mindegyike egy hülyén megírt pluginen keresztül történik, ami a többi CMS-sel kapcsolatban is elmondható. A másik, amivel számolni kell, hogy a pluginek az egész portál erőforrásigényét egészen elképesztően megnövelhetik.

A shared hoszting szolgáltatók 5-15 USD-ért kínálnak olyan LAMP-környezetet, amire több tartalomkezelő rendszer is telepíthető, viszont éppen azért, mert több száz, esetleg több ezer ügyfél osztozik egy szerver – ami jó esetben nem virtuális gép – erőforrásain, előfordulhat, hogy valakinek a megkergült vagy feltört webhelye miatt az összes többi, azonos szervert használó ügyfél oldalai akadoznak vagy konkrétan elérhetetlenek lesznek. De az is előfordulhat, hogy a hoszting szolgáltató figyelmezteti az ügyfelet, hogy túl sok rendszer erőforrást használ, ezért vagy váltson egy drágább platformra, esetleg szó nélkül jegelik a webhelyét. A keresőmotorok számára is messze nem mindegy, hogy egy oldal milyen sebességgel tölt be, milyen a rendelkezésre állása, ha pedig van valami, amit sosem szabad figyelmen kívül hagyni, hogy a weben egy tartalom akkor létezik, ha könnyen megtalálható.

A webhoszting review-oknak sose higgyünk, az a forrás, ami talán a legteljesebb áttekintést ad a webhoszting piac gazdaságtani és IT részéről is, a Strategies for Web Hosting and Managed Services kötet (Doug Kaye), ha a cloud előtti időket nézzük, amit 2001-ben adtak ki ugyan, beszédes, hogy máig a legjobbra értékelt könyvek közt van.

A jelenséggel kapcsolatban eléggé sokat mond, hogy a shared hoszting szolgáltatók közül többen kimondottan WordPress-hosztolásra optimalizált csomagot kínálnak, persze jóval drágábban, holott technikailag, elvben mindkettőnek ugyanazt kellene teljesítenie.

Mindegy is, hogy WordPressről vagy más elterjedt CMS-ről van szó, egyre ritkábban képzelhető el olyan, amikor valóban indokolt saját tárhelyen futtatni a tartalomkezelőt.

VPS? Jó ötletnek tűnik. WP-t VPS-en üzemeltetve kitűnően látható, hogy hogyan zabálja az oldal az erőforrásokat még akkor is, ha csak néhány látogatója van egyidejűleg. És persze ott folyamatosan ott a kockázata annak, hogy mikor töri fel egy bot vagy egy unatkozó hülyegyerek az egészet vagy akár mikor törik fel az egész VPS-t, azt pedig értelemszerűen nem fogja elárulni a szolgáltató, hogy a VPS-ek üzemeltetésénél az elvárható best practice-eket mennyire tartja be, már ha egyáltalán.

Hogyan néz ki mindez számokban? Egy unmanaged VPS havi 8 és 20 USD közé tehető, a managed VPS esetén pedig ugyanolyan teljesítményű virtuális gépért már ennek az árnak a 4-5-szörösét kell fizetni. Itt érdemes megtorpanni egy pillanatra: egy teljes egészében általunk menedzselt virtuális gép operációs rendszerét, oprendszeri szolgáltatásit, adatbázismotorjait és úgy egyáltalán mindent, ami a webszerver működéséhez szükséges, annak összes moduljával együtt magunknak kell rendszeresen frissíteni, ellenőrizni, ami azért nem automatizálható 100%-ig. Ha pedig valaki cPanel, Plesk, Webuzzo vagy hasonló mellett dönt, hogy webes felületen végezhesse el a leggyakoribb feladatokat, azért szintén fizethet havi díjat, arról nem is beszélve, hogy ezek ugyancsak eszik a rendszererőforrásokat amellett, hogy éppen ezeknek az adminisztrációs felületeknek a szoftveres hibái könnyítik meg egy-egy támadó dolgát.

Összefoglalva, hacsak valaki nem feketeöves guruja a webszerverek üzemeltetésének, havi 15-20 USD-nál nem jön ki olcsóbban és még így sincs rá semmi garancia, hogy ne omoljon össze esetleg az egész egy előre nem látható hiba miatt vagy ne váljon más okból elérhetetlenné.

Ezek után érdemes megnézni, hogy mennyibe fáj, ha a WordPress-oldalt maga a WordPress.com hosztolja: https://wordpress.com/pricing/ Lám-lám, szinte ugyanannyiba kerül, esetleg még olcsóbb is, mintha mindent saját magunknak kellene beállítanunk egy webszerveren a nulláról, a WordPress.com-on viszont a biztonságtól kezdve a rendelkezésre álláson át mindenért a WordPress staffja felel.

Azaz persze, mindig lehet próbálkozni olcsóbb megoldással, emellett a behavioral economics nagy kérdése, hogy hogyan lehet piacon még 2018-ban is olyan szolgáltató, amelyik a tipikusan összehasonlíthatalanul gyengébb teljesítményű és rendelkezésre állású hoszting csomagot el tudja adni drágábban is, mint amennyibe az egy USA-beli szolgáltatónál kerül. Az olcsóság nagyon sokba fog kerülni, ami ráadásul nem derül ki azonnal, de még a pénzvisszafizetési garancia időtartalma alatt sem. Nemrég azzal érveltünk, hogy olyan szervezeteknek, mint Vatikán állam, a Spotify vagy éppen a Facebook, zsebpénz lenne lefejleszteni vagy házon belül hosztolni egy saját blogmotort, mégis egy az egyben a WordPressre bízzák, nem véletlenül.

Amit még érdemes figyelembe venni, hogy akár saját magunk által hosztolt CMS-ről, akár felhőben hosztolt megoldásról van szó, maga a megjelenés olyan mértékben testre szabható, hogy például az erdetileg mikroblogként használt Tumblr minden további nélkül átírható úgy, hogy az egy komoly hírportálként jelenjen meg. Vagy éppen a Blogspot.com-on létrehozott blog sablonja átírható olyan layouttal, hogy az egy életrajzi oldal legyen és így tovább. Persze amivel számolni kell, hogy a Tumblr vagy a Blogspot esetén csak a CSS definíciója több ezer kódsor lehet, mivel minden lehetséges funkcióhoz definiálni kell a megjelenést, ráadásul a mobileszközökre külön! A WordPress.com-on hosztolt oldal esetén viszont nem vagy csak nagyon korlátozottan nyúlhatunk bele a kódba, a theme-be viszont általában igen. Hogy bonyolultabb legyen, a Tumblr nem világos okból, de még egy saját leírónyelvet is bevezetett.

A Blogspot és a Tumblr teljesen ingyenes, költeni akkor kell rá, ha valakinek egy egyedi, profi dizájner által varrt skint szeretne használni, egyébként a cég dizájnerének kell egyedivé varázsolni az eredetileg sokszor egyenesen szörnyszülőtt sablonokat.

Persze végtelen érv hozható fel pro és kontra, ha CMS-ről van szó, mi több, a használt technológiáktól függően lehet, hogy valakinek mégis az a megoldás fog jobban tetszeni, hogy ha nem is a nulláról, de végülis csupasz keretrendszerekben dolgozva készíti el a saját webhelyét, ez viszont feltételezi, hogy a fejlesztő egyszerűen elhivatott a webprogramozással kapcsolatban, ezért fejleszt unikális rendszert, ami viszont már alighanem csak ütős időbeli és anyagi ráfordítás mellett lehetne átírható olyan CMS-sé, amit mondjuk egy óriási cég több száz alkalmazottjának kell használnia alkalomadtán.

Némileg ellent mondva annak, amivel indult a poszt, egyéni és mikrovállalati környezetben van és jóideig lesz is helyük az egyedi fejlesztésű rendszereknek, mi több, kitűnő ugródeszka egy teljesen saját megírása annak, aki behatóan szeretne foglalkozni később a nagy, elterjedt CMS-ekkel vagy azok moduljaival.

Nincs kikezdhetetlen válasz arra, hogy melyik megoldás a legjobb, még akkor sem, ha eléggé világosan meghatározott, hogy milyen, mekkora szervezet mire szeretné használni a portálmotorját.

Stay tuned, a Microsoft webes szolgáltatásokra kihegyezett és az Amazon AWS cloudjára hamarosan visszatérünk, addig is nosztalgiázzunk el ezen a kedves kis semmiségen a temetetlen múltból.

Szerző: bardóczi ákos

ORCID, Google Scholar ID, ResearcherID, ResearchGate, MTMT.hu? Find me!