Ady Endre: egy CMS, amelyet úgy építettünk, hogy túléljen minket

Ennek a naplónak minden más bejegyzése olyasmiről szól, amit magunknak építettünk — egy koncepcióról, egy demóról, egy módról, hogy megmutassuk, mi lehetséges, anélkül hogy bárkinek felelnénk a saját megítélésünkön kívül. Az Ady Endre nem ilyen. Ez egy valódi ügyfél: Zágráb legrégebbi és legnagyobb magyar kulturális egyesülete, amelyet 1932-ben alapítottak, kilenc aktív szakosztállyal, és egy önkéntes személyzettel, amelynek olyan weboldalra volt szüksége, amely még akkor is az övék marad, amikor mi már régen nem vagyunk a szobában.

Ez olyan módon változtatja meg a briefet, amit érdemes őszintén elismerni. Egy koncepciós projekt az ízlésnek felel. Egy ügyfélprojekt egy 94 éves intézmény mögött valami nehezebbnek felel: működni fog-e ez még öt év múlva is helyesen, olyan emberek vezetésével, akik egyetlen sornyi kódot sem írtak belőle?

A valódi korlát nem a design volt

A tervezési probléma valódi volt — egy meleg, szerkesztői, papír-és-tinta hangulatú identitás, a magyar népművészetből merített tépett naptárlap motívummal, Framer Motionban felépítve, hogy az oldalátmenetek kézzel készítettnek hassanak, ne sablonosnak. De ez nem volt a nehéz rész, és túlértékelném a projektet, ha mást állítanék.

A nehéz rész az volt, hogy az egyesület teljes intézményi emlékezete — az 1932-es alapítástörténet, kilenc szakosztály tevékenységi története, egy évekre visszanyúló hírarchívum — sosem volt igazi otthona, és aki legközelebb vezetné az oldalt, fejlesztőnek kellene lennie ahhoz, hogy közzétegyen egy hírt vagy hozzáadjon egy elnökségi tagot. Egy szép oldal, amelyet csak mi tudnánk karbantartani, a rossz problémát oldotta volna meg.

Három technikai döntés, és miért számított mindegyik

A Vite mellett döntöttünk, nem a Next.js mellett — tudatosan, nem alapértelmezésből. Ez nem egy SEO-kritikus tölcsér, ahol a szerveroldali renderelés megéri a komplexitását. Ez egy szerkesztői, animációban gazdag oldal, ahol a nyilvános oldalak és az admin CMS egy kódbázist osztanak meg, és a Vite fejlesztési sebessége itt fontosabb volt, mint egy olyan gépezet, amire ennek a projektnek sosem lett volna szüksége. A Next.js-hez nyúlni minden projektnél, csak mert ez az alapértelmezett, pontosan az a fajta döntés, amely biztonságosnak tűnik, pedig nem az — a megfelelő eszköz attól függ, mit kell ténylegesen tennie az oldalnak.

Egy automatikus fordítási folyamatot építettünk, gyorsítótárazással és egyedi kezeléssel, nem egy bővítményt. A hírarchívum eredetileg csak horvát nyelvű volt. Automatikusan átültetni magyarra és angolra a probléma könnyű 80%-a; a nehéz 20% annak biztosítása, hogy a folyamat soha ne torzítsa el magának az egyesületnek a nevét, a szakosztályok megnevezéseit, vagy a szervezetre jellemző kifejezéseket — pontosan azokat a szavakat, amelyeket egy általános fordítási réteg leggyakrabban elront, és amelyeket egy kulturális egyesület a legkevésbé engedhet meg magának, hogy félrefordítva lásson a saját weboldalán.

A Supabase-t használtuk, szerepkör-alapú sorszintű biztonsággal, nem egy közös admin bejelentkezéssel. A híreknek, szakosztályoknak, elnökségi tagoknak, eseményeknek és dokumentumoknak valódi relációs struktúrára volt szükségük — és valódi határokra. Egy önkéntes szerkesztőnek, aki egy szakosztályt kezel, ne lehessen hozzáférése — vagy akár csak útja — bármihez, ami a saját szerepén kívül esik. Ez nem egy utólag hozzáadható funkció; az adatbázis tényleges formájának kell lennie a legelejétől fogva.

Ami majdnem félrement, csendben

Az egyesület ingyenes szintű adatbázison fut, ami helyes döntés egy nonprofit szervezet költségvetéséhez, és rossz döntés, ha senki nem számol azzal, mit is csinálnak valójában az ingyenes szintek: elalszanak. Egy látogató, aki egy hideg adatbázisba fut bele, egy több másodperces fennakadást tapasztal ott, ahol azonnali oldalbetöltésnek kellene lennie — egy olyan intézménynél pedig, amelynek teljes üzenete az, hogy "találd meg itt a közösségedet", ez az első benyomás szinte bárhol másnál jobban számít. Hozzáadtunk egy kis ütemezett feladatot, amely hetente pingeli az adatbázist, épp elég gyakran ahhoz, hogy ne hűljön ki teljesen. Ezt a döntést senki nem fogja soha észrevenni. Pontosan ez a lényeg.

Miért érződött ez máshogy

A napló összes többi projektjénél magunk hozhattuk meg az összes döntést. Itt minden döntésnek túl kellett élnie a találkozást olyan emberekkel, akik nem fejlesztők, nem olvasnak dokumentációt, és a saját idejüket önkéntesként adják egy 94 éves közösség fenntartásáért. A siker mércéje nem az volt, hogy "ez lenyűgözőnek tűnik-e" — hanem hogy "képes-e valaki, aki még sosem nyúlt CMS-hez, közzétenni a jövő havi hírt anélkül, hogy minket hívna".

Ez másfajta nehézség, mint amit bármelyik koncepciós projekt kér tőlünk, és ebből a fajtából szeretnénk többet.