Megújultunk. 15 év webes tapasztalattal. Saját weboldal 14 napig ingyen.
Navigáció
Weboldal Bérlés
Kipróbálom ingyen

Mi van a motorháztető alatt? #1 – Így épül fel a Weboldal Bérlés rendszerarchitektúrája

Ez a sorozat nem arról szól, hogy melyik gombot kell megnyomni az adminban. Megmutatjuk, mi történik mögötte: hogyan épül fel a Weboldal Bérlés saját MVC-alapú, multi-tenant rendszere, hogyan kapcsolódnak egymáshoz a blokkok, variánsok, weboldal-specifikus adatok és a frontend renderelés – és miért nem egy WordPress-telepítésből vagy white-label site builderből áll a szolgáltatás.

A Weboldal Bérlés kívülről egy szerkeszthető, moduláris weboldal-szolgáltatás. Belülről viszont ennél jóval érdekesebb: egy saját fejlesztésű, több weboldalt kiszolgáló alkalmazás, ahol ugyanaz a közös core kezeli a tenant-feloldást, az adminisztrációt, a modulokat, a renderelést és a rendszerfunkciók jelentős részét.

Ez a „Mi van a motorháztető alatt?” sorozat nem felhasználói kézikönyv. Itt nem azt nézzük meg, hol lehet átírni egy gomb szövegét, hanem azt, mi történik technikailag a Mentés és a böngészőben megjelenő HTML között. Ha előbb a szolgáltatás megújulásának háttere érdekel, érdemes elolvasni a Megújult a Weboldal Bérlés című bevezető cikket.

Nem WordPress, és nem white-label site builder

A Weboldal Bérlés nem egy WordPress-telepítésre épített szolgáltatás, és nem egy külső weboldalépítő white-label felülete. Ez nem értékítélet ezekről a rendszerekről: egyszerűen más architekturális döntés.

Saját rendszer esetén a routing, az adatmodell, a modulstruktúra, a frontend renderelés, a SEO-réteg, a képkiszolgálás és a teljesítménykritikus működés ugyanabban a fejlesztési környezetben kontrollálható. Ha például egy modul HTML-struktúráján vagy egy LCP-kritikus erőforrás betöltésén változtatunk, nem kell egy külső sablon, plugin vagy builder által meghatározott absztrakcióhoz alkalmazkodnunk.

Technikai röviden: nem weboldalakat másolunk egymás után, hanem egy közös alkalmazásmagot fejlesztünk, amelyből több önálló weboldal működik.

Az alap: saját MVC és közös alkalmazásmag

A rendszer szerveroldali felépítésének egyik alapelve az MVC-szerű felelősségszétválasztás. Nem azért, mert az „MVC” önmagában minőségi garancia, hanem mert egy növekvő rendszerben nagyon gyorsan kezelhetetlenné válik, ha a route-kezelés, az üzleti logika, az SQL és a HTML ugyanabban a fájlban él.

RétegFő feladat
Router / ControllerKérés feloldása, jogosultság, input és a megfelelő alkalmazási folyamat indítása.
Core / ServiceÚjrahasznosítható üzleti és rendszerlogika, például renderelési, SEO- vagy médiafolyamatok.
Repository / ModelAdatbázis-lekérdezések, tenant- és funkcióspecifikus adatok kezelése.
View / RendererA már feloldott adatokból és konfigurációból a tényleges HTML előállítása.

A lényeg nem a mappanevekben van, hanem abban, hogy az egyes rétegeknek legyen világos felelősségük. Ez azért különösen fontos, mert ugyanaz a rendszer egyszerre szolgál ki publikus oldalakat, ügyféladmin-funkciókat és központi rendszerfolyamatokat.

Multi-tenant: egy core, több önálló weboldal

A Weboldal Bérlés egyik kulcsa a multi-tenant működés. Egy kérésnél először azt kell feloldani, hogy melyik weboldalhoz – tenanthez – tartozik. Ehhez kapcsolódik a saját domain, a tartalom, a modulkonfiguráció, a vizuális beállítások és az engedélyezett funkciók.

egy közös core → több tenant → saját domain + saját tartalom + saját konfiguráció

Ez nagy különbség ahhoz képest, amikor minden ügyfélhez készül egy külön CMS-telepítés. Itt egy központi fejlesztésből lehet új funkció, hibajavítás vagy technikai SEO-fejlesztés minden érintett weboldalon – miközben a weboldalak adatai és beállításai tenant-szinten külön maradnak.

Külön CMS, white-label builder vagy saját multi-tenant rendszer?

Nincs univerzálisan „helyes” architektúra. A választás attól függ, mit akarunk kontrollálni, hogyan akarunk frissíteni, és milyen terméket építünk. A Weboldal Bérlésnél a központilag fejleszthető szolgáltatás volt az egyik fő szempont.

SzempontKülön CMS-telepítésekWhite-label builderWeboldal Bérlés
KódbázisWeboldalanként külön példány vagy erősen szétágazó telepítésekA szolgáltató platformjaKözös saját core
FrissítésTelepítésenként is feladat lehetA külső platform ütemezése szerintKözponti release-ekkel
Frontend kontrollMagas, de sablon- és pluginfüggő lehetA builder lehetőségeihez kötöttSaját renderer és asset-réteg
AdatokKülön telepítések adatmodelljeKülső platform adatmodelljeSaját tenant-specifikus adatmodell
Új rendszerfunkcióTöbb telepítésen kell kezelniAPI- és platformkorlátok közöttA közös core-ban fejleszthető
Központi hibajavításVerziószóródás nehezíthetiA platformtól függEgy fejlesztési ágon kezelhető

A weboldal nem statikus oldal, hanem konfigurált modulfa

A publikus oldal felépítése modulokból áll. A rendszer szintjén érdemes három fogalmat különválasztani:

  • blokktípus: milyen funkcionális egységről beszélünk, például hero, USP, tartalom+kép, GYIK vagy kapcsolat;
  • variáns: ugyanannak a blokknak milyen szerkezeti vagy megjelenítési változata használható;
  • site module: az adott tenant konkrét blokkpéldánya, saját tartalommal, beállításokkal és sorrenddel.

Az adatbázisban ez a gondolkodás többek között a module_blocks, module_variants és site_modules rétegeiben jelenik meg. A fontos pont az, hogy egy Hero blokk nem egyszerűen egy előre megírt HTML-részlet: van típusa, variánsa, tenanthez tartozó példánya, tartalma és renderelési logikája.

Mi történik a Mentés gomb után?

Egy adminban elvégzett módosítás leegyszerűsített útvonala így néz ki:

Admin → validálás → adatbázis → site_modules / konfiguráció → variáns-renderer → HTML + szükséges frontend assetek

Vagyis az admin nem közvetlenül HTML-t szerkeszt. Adatot és konfigurációt módosít, amelyből a publikus kérésnél a rendszer felépíti a megfelelő kimenetet. Ez teszi lehetővé, hogy ugyanarra a tartalmi modellre központi renderelési, akadálymentességi, SEO- vagy performance-szabályokat alkalmazzunk.

A közös core előny – és felelősség

A multi-tenant architektúra egyik legerősebb tulajdonsága egyben a legnagyobb felelőssége is. Ha egy hibát központilag javítunk, az nem ötven külön telepítésben marad ötven külön állapotban. Ugyanakkor egy rossz központi módosítás több weboldalt is érinthet.

Ezért a fejlesztéshez hozzátartozik a verziózás, az adatbázis-migrációk kontrollja, a visszafelé kompatibilitás, a célzott regressziós tesztelés és az, hogy egy új funkció ne írja felül véletlenül a már működő tenantok viselkedését.

Nem microservice-színház, hanem világos határok

Egy ilyen rendszerhez nem attól lesz „enterprise” az architektúra, hogy mindent külön service-be és queue-ba bontunk. A fontosabb kérdés az, hogy a felelősségi határok egyértelműek-e, a közös funkciók újrahasznosíthatók-e, és egy módosítás hatása tesztelhető-e.

A Weboldal Bérlésnél ezért a cél nem a technológiai divatszavak maximalizálása, hanem egy olyan közös platform fenntartása, amelyhez új blokk, új extra szolgáltatás vagy új technikai réteg úgy adható hozzá, hogy a meglévő weboldalak továbbra is stabilan működjenek.

Mit nyerünk ezzel fejlesztőként?

  • egy helyen javítható közös működés;
  • központilag fejleszthető SEO-, teljesítmény- és médiafolyamatok;
  • újrahasznosítható modulok és adminfunkciók;
  • tenant-szintű tartalom és konfiguráció közös technikai szabályok mellett;
  • kiszámíthatóbb release- és migrációs folyamat;
  • és ami hosszú távon talán a legfontosabb: nem különálló weboldalakat, hanem továbbfejleszthető platformot építünk.

GYIK

Gyakran ismételt kérdések a Weboldal Bérlés rendszerarchitektúrájáról

Rövid technikai válaszok az MVC, a multi-tenant működés és a moduláris renderelés legfontosabb kérdéseire.

Nem. A Weboldal Bérlés saját fejlesztésű, MVC-szerű felépítésű rendszer. Ez nem WordPress-kritika: a saját platform mellett azért döntöttünk, hogy a routingot, az adatmodellt, a renderelést, a SEO-réteget és a teljesítménykritikus működést központilag tudjuk fejleszteni.

Azt, hogy egy közös alkalmazásmag több önálló weboldalt szolgál ki. A kéréshez a rendszer feloldja a megfelelő tenantet, majd annak saját domainjét, tartalmát, moduljait, konfigurációját és engedélyezett funkcióit használja.

Nem. Közös a modul- és renderelési rendszer, de tenantonként eltérhet a blokkok összeállítása, sorrendje, variánsa, tartalma, vizuális beállítása és több más konfiguráció. A közös core nem azonos weboldalakat jelent.

Az admin a bevitt adatot validálja és a tenant megfelelő modulkonfigurációjához menti. A publikus megjelenítésnél a rendszer ezt az adatot a blokk típusához és variánsához tartozó renderelési logikán keresztül alakítja HTML-kimenetté.

A közös core miatt egy hibás központi módosítás hatása valóban szélesebb lehet, ezért fontos a verziózás, a migrációk kontrollja, a visszafelé kompatibilitás és a regressziós tesztelés. Cserébe a javítások és rendszerfejlesztések is központilag vezethetők át.

Sok. Ha a HTML-struktúra, a meta- és schema-generálás, a képkiszolgálás vagy az assetek betöltése közös renderelési és core-rétegen keresztül működik, akkor a SEO- és performance-fejlesztések rendszerszinten, következetesen alkalmazhatók. A sorozat következő része ezt bontja ki részletesen.

Kapcsolódó cikkek