Mennyire érdemes a lehető legjobban "tehermentesíteni" egy webszervert és rábízni a kliensoldalra az ott elvégezhető "munkák" nagy részét?

Nem tul jo otlet kiadni a kezedbol a kontrollt, hogy kliensoldalon valami script kiddie nekialljon televerni a 'kosarat' szemettel, hogy azzal DOS-olja a webszerveredet, tomcat-edet, meg az adatbazist.

Alapvetes: a kliens nem megbizhato. Nem, akkor sem, ha te feltetelezed rola, barki es barmi lehet mogotte.

Egyáltalán nem látom a példa alapján, hogy ez hogyan lenne extra támadási felület.

Semmi hátránya nincs ennek ha még pénztárnál ÉS rendelés leadásakor is ellenőrzöd szerver oldalon.

A válasz szerintem függ a körülményektöl:

Ha már van egy webshop, ahol serveroldalon történik mindez és nincs probléma a server teljesítményével, szerintem nem kéne átírni.

Ha van teljesítményprobléma, még akkor is olcsóbb lehet erösebb vasra költözni, mint totál átalakítani a szoftvert.

Ha még csak a tervezési fázis elején jársz, akkor jó lehet a kliensre bízni minél több dolgot, hogy tehermentesítsd a servered.

Viszont arra érdemes figyelni, hogy itt is van egy tradeoff:

A serveroldali kódnak csak egy platformot kell supportálnia: azt a servert, amin fut. A kliensoldali kódnál számításba kell venned azt, hogy különbözö böngészök különbözö verziói különbözö OS-en futnak. Persze a mai világban ezt már megoldják helyetted mindenféle js libek, de ugye azokat is be kell húzni -> ezzel növeled a termék komplexitását.

Attól is függ a válasz, hogy az emberek, akik fejlesztik, milyen skillekkel rendelkeznek: Ha van pl 3 backendesed meg egy frontendesed, akkor lehet, hogy jobban jársz, ha nem tolsz ki túl sok mindent a kliensoldalra.

Ha a körülményektöl eltekintünk, feltételezzük, hogy végtelen eröforrásod van, szerintem mindkét megközelítés egyformán jó.

Alapelv, hogy csak olyan feladatot bízunk a kliensre, aminek a hibás elvégzése nem okoz instabilitást. Mondjuk bejelentkezéskor egy kliens oldali szkript ellenőrizheti, hogy a beírt e-mail cím formailag helyes-e, vagy egy jelszóváltoztató lapon azt, hogy a két beírt jelszó egyezik-e. Nagyjából ennyi az, amit a kliensre illik rábízni. A kosár kezelését és nyilvántartását nem véletlen, hogy egyre több helyen szerver oldalon végzik. Véletlenül bezárja a böngészőt, lefagy a gép, vagy egyszerűen csak elindul munkába, a vásárlást még nem fejezte be, mennyire kényelmes, ha út közben telefonról ott folytathatja, ahol abbahagyta.

A szerver terheltésge pedig erősen túl van gondolva. Ha ez egy kis webáruház, akkor nem fog a szerver összerogyni az óránként kb. 9 adatbázisművelet miatt. Ha meg egy kifejezetten forgalmas webáruházról van szó, ahol ez tényleg számottevő többletterhet jelentene, akkor meg kell, hogy legyen pénz erősebb szerverre.

A szerver terheltsége nem kell témának lennie manapság. Sőt, ezt előre nem is fogod tudni megmondani. Lehet, hogy elegendő 2 magos, 4 GB-os rendszer is, és flottúl fog menni. Vagy lehal, mint a Signal szerver parkja, mikor mondja Elon Musk, hogy használj Signal-t. Azért mindkét véglet van! Erre azt szokták mondani, hogy "Jósold meg a használatot.", "Kezd kicsivel, és majd skálázd." és "Monitorozd az alkalmazásod terheltségét".

A kliens oldallal kapcsoaltban, szerintem nyugodtan rábízgatsz olyan dolgokat. Én azt szoktam mondani, hogy ami user/browser specifikus, akkor az kiszervezhető. Én preferálom a STATELESS megközelítést, mikor nincs szerver oldali SESSION, lásd API-k. Tehát minden kérés független egymástól, de tartalmazhat olyan adatot, ami azonosítja a felhasználót. Pl.: JWT ( [link] ), és ezt feldolgozva már tudom kiről van szó, így egy User<=>Server<=>Server (azaz microservice-ek) folyamon is tovább tudom dobni a JWT-t és a másik szerver is tudni fogja, milyen jogosultságaid vannak, amit a JWT tárol.

Igen.. a JWT felhasználónál van, és tartalmazza a jogosultságait is, ami digitálisan alá is van írva, tehát a JWT érvénytelen lesz, ha kézzel belemókol. ;) Amúgy az ilyen aláírásos dolgokat, amit a szerver oldalon tudsz ellenőrözni, és onnan is adod ki, azt bátran kliens oldalra kiadhatod, ha nem tartalmaz érzékeny adatot.