Alkalmazásmodell és renderelési stratégia választása

Célok

A lecke végére egy adott feladathoz meg tudod indokolni az alkalmazásmodell (MPA vagy SPA) és a renderelési stratégia (SSG, SSR, CSR vagy hibrid) választását, és fel tudod sorolni a döntés szempontjait.

Miért nincs „legjobb” megoldás?

Az eddigi leckék különböző megoldásokat mutattak: más a navigáció, más a renderelés, és mindegyik valamit nyer, valamit veszít. A web.dev összegzése is az, hogy előbb mérni kell a szűk keresztmetszetet, a statikus vagy szerveroldali megoldás sokszor elég, és a minimális JavaScript segít az interaktivitás megőrzésében. A választás attól függ, milyen tartalmat kell megjeleníteni, milyen gyakran változik, mennyi interakció kell, és mi történjen lassú vagy hiányzó hálózatnál.

Három különböző feladat

• Az egyetem hivatalos kurzusleírása sokaknak ugyanaz, ritkán változik, és fontos, hogy közvetlen linkről olvasható legyen. Egy statikusan előállított, többoldalas szerkezet jól illik hozzá.
• A jelentkezési felület friss férőhelyadatot és szerveroldali döntést kíván: itt lehet értelme kéréskor előállított HTML-nek, API-frissítésnek vagy hibrid megoldásnak.
• A közös ábraszerkesztő sok helyi interakcióval és folyamatos adatcserével jár: kliensoldali alkalmazásként természetesebb.

Ezek példák, nem kötelező technológiai előírások.

flowchart TD
    C[Felhasználói feladat] --> T[Tartalom frissessége]
    C --> I[Interakció mértéke]
    C --> N[Navigáció és megoszthatóság]
    C --> O[Offline igény]
    T --> V[Alkalmazás- és renderelési döntés]
    I --> V
    N --> V
    O --> V

Két külön döntési tengely

1. Navigáció (MPA–SPA): a nézetváltáshoz rendszerint új dokumentumot kérünk (6.1), vagy a kliensprogram cseréli a nézetet?
2. Renderelés (SSG–SSR–CSR): hol és mikor áll elő a kezdeti fontos tartalom: előre (6.4), kéréskor a szerveren (6.3), vagy a böngészőben (6.2)?

A két döntés összefügg, de nem olvad össze. Lehetséges kombinációk:

	SSG (előre)	SSR (kéréskor)	CSR (böngészőben)
MPA	statikus webhely, oldalanként HTML	szerveroldali oldalak, minden navigáció új HTML	az oldalak üresek, a böngésző tölti fel
SPA	előrenderelt kezdőnézet, utána kliensnavigáció	szerveroldali kezdőnézet, utána kliensnavigáció	klasszikus SPA: váz + program + API

Az alkalmazás külön részei eltérő választ is kaphatnak. A kurzusleírás lehet statikus, a szabad helyek száma API-ból frissülhet, az űrlap ellenőrzése pedig részben a böngészőben történhet. A tényleges jelentkezést a szervernek kell elfogadnia vagy elutasítania. A „hibrid” nem öncélú összetettség: akkor indokolt, ha a részek frissességi és interakciós igénye valóban eltér.

A döntés szempontjai

1. Első használható tartalom: olvasásra szánt oldalnál a lényeges szöveg minél hamarabb jelenjen meg (9. és 10. fejezet).
2. Interakció: gyakori nézetváltás és helyi szerkesztés több kliensoldali programot kíván.
3. Frissesség: a statikus leírás és a pillanatnyi férőhelyszám más kezelést igényel (6.4).
4. Megoszthatóság és navigáció: egy konkrét kurzus URL-jének frissítés után és másik eszközön is működnie kell (6.5).
5. Kereshetőség és előnézetek: ha a keresőnek és a hivatkozás-előnézetnek látnia kell a tartalmat, az a nyers válaszban legyen (6.2, 9. fejezet).
6. Offline igény: service worker kell, és meg kell határozni az offline határát (6.6).
7. Eszközök és hálózat: nagy mennyiségű JavaScript gyengébb eszközön később reagál.
8. Üzemeltetés és csapat: a statikus kiszolgálás egyszerű és olcsó lehet, az SSR szerverkapacitást és figyelést kér.

Nincs stratégia kompromisszum nélkül: ha minden kéréskor nehéz szerveroldali munkát végzünk, a válaszidő nő; ha statikus tartalom mellett rossz a közzététel frissítése, régi adat marad kint; ha sok JavaScriptre építünk, az első használható állapot késhet.

Végigvezetett példa: a Kurzuspont architektúrája

Rész	Navigáció	Renderelés	Indok
Szabályzatok, félévi kurzusleírások	MPA	SSG	Ritkán változik, kereshető, CDN-ről gyors.
Kurzusoldal a szabad helyek számával	MPA	SSG + API-frissítés (hibrid)	A leírás statikus, a szám élő.
Jelentkezési felület	SPA	CSR, a kezdőnézet SSR-rel	Gyors szűrés és visszajelzés; a jelentkezést a szerver dönti el.
„Saját jelentkezéseim”	SPA része	CSR vagy SSR	Személyes, nem gyorsítótárazható közösen.
Olvasható kurzusanyag offline	Bármelyik	+ service worker	Cache a már látott anyagokra.

Látható, hogy egy valódi rendszer ritkán egyetlen stratégia: a döntést részenként, a feladat igényei szerint hozzuk meg, és mindig dokumentáljuk, mit nyertünk és mit adtunk fel.

Gyakori tévhitek

Állítás	Pontosítás
„Az SPA mindig modern, az MPA elavult.”	Más feladathoz más navigációs modell célszerű.
„Az SSG csak egyszerű, interakció nélküli oldalhoz jó.”	Statikus HTML mellett dinamikus elemek is működhetnek.
„Az SSR minden esetben gyorsabb, mint a CSR.”	A szerver, a hálózat és a kliens munkája együtt számít.
„A service worker minden offline problémát megold.”	Csak a tervezett, tárolható tartalom és művelet működik.
„A hibrid mindig jobb, mert kombinál.”	Csak akkor, ha a részek igénye valóban eltér; különben felesleges bonyolultság.

Röviden

• Két külön döntés: navigáció (MPA–SPA) és renderelés (SSG–SSR–CSR); ezek szabadon kombinálhatók.
• A szempontok: első használható tartalom, interakció, frissesség, megoszthatóság, kereshetőség, offline igény, eszközök és hálózat, üzemeltetés.
• Egy rendszer részei eltérő stratégiát kaphatnak; a hibrid akkor indokolt, ha az igények eltérnek.
• Nincs kompromisszum nélküli stratégia: dokumentáld, mit nyertél és mit adtál fel.

Ellenőrző kérdések

1. Melyik két döntést kell külön meghozni egy új webalkalmazás tervezésekor?
2. Miért illik a szabályzatok oldalához az MPA és az SSG?
3. Mikor indokolt a hibrid renderelés a jelentkezési felületen?
4. Mit nem old meg a service worker a jelentkezés esetében?

Tanulási források

• Rendering on the Web (web.dev) — a lehetőségek és kompromisszumaik áttekintése, angolul.