sjozsef blog reloaded

Jó ideje nem volt időm a blogra, úgyhogy az utóbbi pár évben nem hogy új poszt nem került ki, még arra sem volt időm, hogy költözés után összerakjam az új szerveren, ezért hónapokig nem is volt elérhető. Ennek részben az is volt az oka, hogy nem akartam már beüzemelni a régi WordPress blogot, mert már vagy egy éve fejlesztgettem az új verziót.

Most jutottunk el odáig, hogy elő tudtam rukkolni egy MVP -vel, amelyben bár csak az eredeti scope egy kis részét sikerült megvalósítani, de legalább valami van a soha el nem készülő csillagromboló helyett. Aztán majd fejlesztgetem, ahogy időm engedi (=valószínűleg soha többet nem fogok hozzányúlni a kódhoz).

Az új blog teljesen új technológiai alapokon készült, más a célom is vele és ehhez igazodó új design is levődött.

Új célok

A régi blog elsődleges célja az volt, hogy elsősorban KKV ügyfelekkel dolgozó freelancerként a célközönségemmel tudjak valahol kommunikálni az ő nyelvükön, az őket érdeklő problémákról, hogy így szerezzek több megkeresést. A szakmai cikkekkel is inkább a szakértői státuszomat próbáltam erősíteni a céközönség szemében.

Ezzel szemben az új blog elsődleges célja a tudásmegosztás. Mostantól egyrészt azoknak írok, akik tanulni akarnak, másrészt saját magamnak. A komolyabb szakmai tartalmak írása ugyanis egy kiváló eszköz bizonyos területeken már meglévő, de kissé felületes tudás elmélyítésére, megszilárdítására, felelevenítésére. Tanítva tanulás.

Új design

Mivel a blog mostantól elsősorban a szakmának szól, egy meglehetősen geek, kicsit terminálemulátoros, direktronda vagy csak simán ocsmány, de mindenképpen egyszerű, letisztult és használható designt kapott (ez volt legalábbis a terv).

Az is fontos volt, hogy ne legyen kötelező cover képeket használni a bejegyzésekhez, ugyanis szerintem hülyeség oda nem illő stock fotók keresésével töltenem az időmet csak azért, mert a legtöbb blogon vannak oda nem illő cover képek, így rögzült, ez a normális. Meg hát ugye, a felesleges stock fotók felesleges sávszélt is jelentenek. Szóval semmi értelme szerintem, hogy minden bejegyzésnél legyen egy billentyűzetes/kávés/kódos/hipszerszűrős, esetleg egy adatközpontos/optikai kábeles/rackes, vagy még rosszabb, mátrixos fotót tegyek minden bejegyzés mellé.

Szempont volt még, hogy legyen olvasható, használható és brutálisan gyors. Ezzel kapcsolatban még tényleg lesznek további fejlesztések (de az is lehet, hogy nem). Tervben van egy akadálymentesítéses kör is (a cél a tudásmegosztás -> a tudás mindenkié -> akadálymentes weboldalak kellenek).

A design amúgy az én munkám, szakembert nem vontam be egyelőre, de a várhatóan soha meg nem valósuló terveim között szerepel azért, hogy igazi designer segítségével, profibban redesignolom vagy ráncfelvarrom majd egyszer.

Új technológiai alapok

Régóta foglalkoztat a JAMStack, amivel kísérletezgetek is egy ideje, régebben cikket is írtam róla az fps blogra. Mivel ez az architektúra tökéletesen megfelel technológiai elvárásaimnak, úgy döntöttem, hogy ilyen alapokon építem fel a blogot.

Frontend

A frontend lényegében egy NuxtJs, ami static a modeban a szerveroldalon le tudja generálni a komplett blogot full statikus inxex.html -ekké. A tartalmakat egy API szolgáltatja neki, de a backendről később. A statikus fájlokat egy sima nginx szolgálja ki.

A NuxtJs segítségével generált statikus site úgy működik, hogy az első lapletöltésnél kapsz egy szerveren előre renderelt dokumentumot, tehát ilyenkor kliensoldalon nincs render (kivéve, ha bizonyos komponenseknél megtiltod a szerveroldali rendert, mert mondjuk kliensoldali state -től függ).

Amikor átkattintasz egy másik aloldalra, akkor a fent említett API -ról letölti az aloldalhoz szükséges tartalmakat, majd újrarendereli az oldalt. Ezzel nem voltam megelégedve, mert felesleges meghívni a dinamikus API -t (ugyanazt fogja mondani, amit a szerveroldali rendereléskor mondott). Ezért a Nuxt payload extractor modul segítségével megoldottam, hogy az api válaszokat szerveroldali rendereléskor mentse le nekem a Nuxt sima json állományokba, amelyeket kliensről elérek. Gyakorlatilag statikosítottam az API -t.

Normális deploy folyamatom még nincs hozzá. Ez az arcitektúra igényelé, hogy fusson egy apró kis szolgáltatás a szervern, ami értesül a tartalmak változásáról és lefuttat egy buildet (újragenerálja az egész blogot). Ezt még nem ugrottam meg, úgyhogy egyelőre ha új tartalmat viszek fel, szépen felmegyek a vpsre és lefuttatom kézzel.

A kód egy része eléggé összecsapott, ezért egyelőre nem teszem elérhetővé, egy alapos refaktor után viszont fel fogom tenni egy public GitHub repóba és fogok írni róla konkrétabban is.

Backend

Szerveroldalon a Sanity.io -ra esett a választásom, ami lényegében egy SAAS headless CMS. Minden vele szemben támasztott követelményemnek megfelel: egyszerű haszálni, gyorsan össze tudtam rakni magamnak a backendet, vállalható admin van hozzá, minden tervezett funkciót meg lehet vele valósítani.

Amúgy igazi fejlesztőpornó. Annyira komolyan vették a headless CMS dolgot, hogy a backendnek itt aztán tényleg lövése nincs arról, hogy a frontend hogyan fogja megjeleníteni az általa szolgáltatott tartalmakat. A rich text dolgokat például a szokásostól eltérően nem markdownban és nem is htmlben tárolja, hanem egy Portable Text nevű formátumban. Lényegében strukturált szöveg, amiből ha weboldalon jeleníted meg, csinálhatsz HTML -t (van is hozzá helper), ha e-bookban, akkor csinálhatsz PDF -et, vagy amit akarsz. Hogy ennek van -e értelme, az jó kérdés egyébként, mert amikor tényleg csak egy egyszerű blogra van szükséged, akkor magasabb komplexitás árán jutsz el ugyanoda, ahová a hagyományos megoldások valamelyikével is eljuthattál volna. Bizonyos projekteknél persze lehetnek előnyei, kis projektnél a block-text-to-html helpernek köszönhetően nem fáj. A koncepció, hogy a backend tényleg nem tud semmit a tartalom megjelenítéséről, mindenképpen menő.

Az admin felülethez gyakorlatilag kapunk egy React alapú keretrendszert, ami telepítés után majdnem tudta azt, amire szükségem volt, alig kellett belenyúlnom. Egyelőre ezt nem is tettem fel sehová, ha hozzá akarok nyúlni a tartalmakhoz, akkor szépen localhoston elindítom, szerkesztek, aztán meg bezárom.

Röviden ennyit a backendről.

Sanity témában biztos fogok még írni a hosszabb távú tapasztalatokról, illetve remélem, minden másról is lesz időm. Addig is minden jót és kösz, hogy elolvastad!