# 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.

- **Eredeti HTML oldal:** [https://weboldal-berles.hu/blog/mi-van-a-motorhazteto-alatt-weboldal-berles-rendszerarchitektura](https://weboldal-berles.hu/blog/mi-van-a-motorhazteto-alatt-weboldal-berles-rendszerarchitektura)
- **AI tartalmi térkép:** [llms.txt](https://weboldal-berles.hu/llms.txt)

- **Megjelenés:** 2026-08-28
- **Kategória:** Weboldal bérlés
- **Szerző:** Szabó Balázs
- **Címkék:** moduláris weboldal, multi-tenant, MVC, rendszerarchitektúra, webfejlesztés, weboldal bérlé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](https://weboldal-berles.hu/blog/megujult-a-weboldal-berles) 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éteg | Fő feladat |
| --- | --- |
| **Router / Controller** | Ké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 / Model** | Adatbázis-lekérdezések, tenant- és funkcióspecifikus adatok kezelése. |
| **View / Renderer** | A 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.

| Szempont | Külön CMS-telepítések | White-label builder | Weboldal Bérlés |
| --- | --- | --- | --- |
| **Kódbázis** | Weboldalanként külön példány vagy erősen szétágazó telepítések | A szolgáltató platformja | Közös saját core |
| **Frissítés** | Telepítésenként is feladat lehet | A külső platform ütemezése szerint | Központi release-ekkel |
| **Frontend kontroll** | Magas, de sablon- és pluginfüggő lehet | A builder lehetőségeihez kötött | Saját renderer és asset-réteg |
| **Adatok** | Külön telepítések adatmodellje | Külső platform adatmodellje | Saját tenant-specifikus adatmodell |
| **Új rendszerfunkció** | Több telepítésen kell kezelni | API- és platformkorlátok között | A közös core-ban fejleszthető |
| **Központi hibajavítás** | Verziószóródás nehezítheti | A platformtól függ | Egy 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.