ugrás a tartalomhoz

Mennyire vastag a vastag kliens?

inf3rno · Okt. 12. (H), 14.00
Amennyire én tudom a vastag kliens pl egy single page application, amikor a presentation nagy részét a kliensre toljuk, az üzleti logika viszont marad a szerveren, mert az előtt csinálunk jogosultság ellenőrzést. Valakivel viszont összevitatkoztunk ezen, mert szerinte a vastag kliens az, amikor az üzleti logika is a kliensre megy, és csak egy adatbázis van a szerveren. Ez utóbbi nekem elég fura, de így utánaolvasva intraneten esetleg előfordulhat, hogy elkövetnek ilyet. Van erről valami tapasztalatotok, esetleg véleményetek? Egyáltalán milyen hátrányai vannak, ha az adatbázisra tesszük a jogosultság ellenőrzést, concurrency kezelését, stb?
 
1

Tinédzser korú emlékeim

mind1 valami név · Okt. 12. (H), 15.26
Tinédzser korú emlékeim szerint vékony kliens ami csak a megjelenítést intézi (browserben, remote desktop stb.), ami ennél több, az vastag kliens.
Tévedés joga fenntartva.
2

Itt arról van szó, hogy az

inf3rno · Okt. 12. (H), 16.57
Itt arról van szó, hogy az alkalmazás logika kell e a vastag klienshez vagy sem. Igazából abban sem vagyok biztos, hogy amit a fazon "alkalmazás logikának" hív, az a business logic, de olyan 90%, hogy arról van szó. Na most a webalkalmazásoknál a business logic sosem kerül a kliensre, mert nem lehet megbízni benne. Ha csak egy böngészős JS alkalmazásról van szó, akkor is egy böngésző pluginnel vagy egy XSS-el bele lehet nyúlni, onnantól meg már bármi bekerülhetne az adatbázisba, ha a kliens dönt róla, esetleg az egész ellopható lenne. A jogosultság ellenőrzés, validáció mindig a szerveren szokott menni. A formai validációt esetleg be lehet másolni a kliensre, hogy kevesebb hibás kérés menjen a szerverre, de nagyjából ennyi. Azért nem értem ezt a megközelítést. Nagyon meg kell bízni a kliensben, ha valaki ezeket át akarja tenni oda. Illetve a jogosultság kezelés eléggé beszűkült kell, hogy legyen, mert az adatbázisnál elég kevés a lehetőség bármi egyedi állítására. Plusz az alkalmazás se nagyon tudja elrejteni azokat a dolgokat, amihez nincs joga az embernek, hacsak nem az adatbázisból szedjük ki ezt az infot. Fura az egész, nem is értem miért csinál bárki ilyen rendszert. Talán asztali alkalmazásoknál tudom elképzelni, ha fájlrendszer helyett adatbázist akarnak használni, de kliens-szerver környezetben nagyon idegennek hat.
3

Nem kell

Pepita · Okt. 13. (K), 09.32
Itt arról van szó, hogy az alkalmazás logika kell e a vastag klienshez vagy sem
Nem kell, de nincs is kizárva.
Szerintem az, hogy mit nevezünk vékony vagy vastag kliensnek, eleve véleményfüggő, és nem is igazán lehet éles határt szabni.
Alkalmazás logika is többféle van, pl xy adat megléte esetén lehet z adatot megadni: ezt ki kell vinned frontendre _is_, hogy addig ne jelenítsd meg a z inputot (vagy disabled), amíg nem használható.
Szóval bármennyire is vastag a kliens, abban egyetértek, hogy egy webalkalmazásnak a biztonsága a szerveren van, annyit tud tenni a FE, hogy borzasztóan egyszerűen validálható adatcsomagokat küld be - így csökkentve a BE terhelését.
4

Hát a fazon váltig állította,

inf3rno · Okt. 13. (K), 14.10
Hát a fazon váltig állította, hogy az a különbség a vékony és a vastag kliens között, hogy a kliensben van e az alkalmazás logika. Én meg ezzel abszolút nem értek egyet. Wikipedia szerint sem ez a különbség, hanem csak annyi, hogy a szerver végzi e a munka nagy részét. ref Mindezt információbiztonsággal kapcsolatos előadás után. Olyan helyzetben vagyok, hogy a szakdolgozathoz témavezetőt kellene választanom, és vagy ő vagy egy másik, aki kevésbé segítőkész. Eddig ez felé húztam, de úgy tűnik, hogy nincs meg a szakmai tudása, vagy legalábbis szoftverfejlesztéshez nem ért, csak hekkeléshez. Nekem meg az előbbi kellene jobban a témámhoz.

Igazából ez egy érdekes trend, hogy manapság mindenki azt akarja eladni, hogy ő mindenhez is ért. Orvosoknál is láttam már rá néhány példát az elmúlt években, de most informatikusoknál is ugyanezt látom. Olyat viszont még nem láttam, hogy valaki beismerte volna, hogy nem ért hozzá. :D
5

Hú, így kissé kemény helyzet...

Pepita · Okt. 14. (Sze), 12.02
szakdolgozathoz témavezetőt kellene választanom, és vagy ő vagy egy másik, aki kevésbé segítőkész
Ez így eléggé gáz, elsőre az jutott eszembe, hogy rá se ránts, az "csak" szakdolgozat, legyen meg a papír, aztán majd elfelejted...
De mi van akkor, ha nem tudod megvédeni?...

Sajnos a piac igénye az (egyre inkább), hogy mindenhez is érts... Saját tapasztalat: junior(!) fejlesztő (pár éve, nem túl rég): ő nem junior, hanem "medior" (előzőleg ilyet senkitől nem hallottam), és fullstack. Sőt, üzemeltetésben (LAMP) is gyakorlott. Az első néhány komolyabb backend hiányosság után (sql injection-től kezdve a kódszervezési hibákig kb minden) óvatosan megpróbáltuk inkább frontend irányába terelni - sajnos hasonló eredménnyel, de legalább biztonsági rések nélkül...
Szóval ma egy huszonéves "friss-hús" szoftverfejlesztőnek lehet sértő a junior kategória gyakorlat, tudás és megfelelő hozzáállás nélkül is.
Olyat viszont még nem láttam, hogy valaki beismerte volna, hogy nem ért hozzá.
Dolgozzunk együtt, én rendszeresen mondok olyat, hogy "ezt még nem ismerem, utána kell nézzek, ha valóban így akarjuk csinálni" :). Szerintem sokkal nagyobb baj az, amikor olyan valaki ajánl egy bizonyos technológiát, aki maga sem ismeri, sőt, lusta is arra, hogy megismerje. Nos, győzd meg őt, hogy az adott cél eléréséhez egy másik technológia sokkal jobb lenne...
7

Egyelőre még mindig nem

inf3rno · Okt. 15. (Cs), 18.50
Egyelőre még mindig nem gondolom úgy, hogy elég tapasztalt lennék hozzá, inkább az elméletét ismerem a szoftverfejlesztésnek, nincs annyira sok gyakorlatom. Meg inkább vállalkozás irányba tendálok még mindig, de majd idővel lehet az lesz, hogy jelentkezek hozzád juniornak, ha meguntam a tengés-lengést és becsődöltem újra a vállalkozással is. :-)

Amúgy erről a képzésről van szó. ref Több a jogi része, mint a technikai, úgyhogy valszeg nem akkora gáz, bármelyiket választom, mert technikai dologról van szó, és szeretnek néha olyat is olvasni sok jogi szöveg után. Konkrétan gépi tanulás a kibervédelemben címen lenne valami szösszenet, és abból is inkább valami egyszerűre koncentrálnék, pl valami egyszerűbb alkalmazás syslogjának a feldolgozása gépi tanulással, és riasztás a rendszergazdának, ha valami rendellenes van. Sőt igazából én csak javaslatot teszek témavezetőre, aztán majd egymás között megbeszélik, hogy kit kapjak. A fazon még fura más szempontból is, mert ilyeneket is mondott, hogy a syslogot is ő csinálta meg, hogy valami magyar tűzfal fejlesztéséhez is hozzájárult meg ilyesmi. Ha rákeresel wikipedian a syslogról az van, hogy valami amcsi találta ki. A google sem talál semmit- róla, ha beírom a nevét, egy fantom. Szóval még akár az is lehet, hogy ez a huszadik álneve. Ki tudja hogy megy ez magasabb szinteken. :D A másik nagyon jól leinformálható prof, bár annak is van egoja ezt olvasva. ref :D Na mindegy, csak legyek túl ezen, aztán tudok GDPR-ezni, meg önkormányzatoknak is dolgozni.

Lehet átgondolom ezt az egészet, és csinálok valami kevésbé technikai jellegűt. Nem biztos, hogy jó kilógni a sorból, és nekem is kevesebb munka. Egyelőre még nem volt téma választás, úgyhogy van időm átgondolni, meg kíváncsi vagyok a listára is, amit felhoznak választhatónak.
10

A "syslog-ng"-t (nem a

BlaZe · Okt. 16. (P), 00.40
A "syslog-ng"-t (nem a syslogot) valóban magyarok csinálták: a Balabit. Simán lehet, hogy igazat mond, ha ott dolgozott :)
11

Állítólag Balazs Scheidler,

inf3rno · Okt. 16. (P), 02.59
Állítólag Balazs Scheidler, akit tanított, de hajlamos egy kicsit magáénak vallani mindent, amit a tanítványai találtak ki ezek alapján.
13

Nem nyert :)

Pepita · Okt. 16. (P), 09.38
idővel lehet az lesz, hogy jelentkezek hozzád juniornak
Két gond van:
- jelenleg tudtommal nem engednek felvenni fejlesztőt
- Te _juniornak_ biztosan nem jöhetsz. :-D

Vállalkozással egyébként nem szükségszerű becsődölni, de kell megfelelő véna hozzá, és szoftverfejlesztésre ma már nem biztos, hogy érdemes egyszemélyes céggel indulni..

A képzés maga egyébként tetszik, kevés igazán jó szakembert ismerek a területen. A témaválasztás érdekes, de szerintem vigyázni kell, hogy ne menjen túlságosan szoftverfejlesztési irányba.
Hát "a másik prof" oldalát olvasva én a javaslathoz is inkább egy pénzt dobnék fel. :)

Lehet átgondolom ezt az egészet, és csinálok valami kevésbé technikai jellegűt.
Csak egy "kibic" véleménye(m): szerintem azzal tényleg jobban jársz.
14

Ja hát, nem mindig jó kilógni

inf3rno · Okt. 16. (P), 16.08
Ja hát, nem mindig jó kilógni a tömegből, meg felesleges kockázatot vállalni. Amit elterveztem, azt meg meg tudom csinálni a képzéstől függetlenül is. Machine learning érdekel, ismerősöm abban dolgozik, úgyhogy van mit olvasgatnom.
6

Attól nem lesz a kliens

BlaZe · Okt. 14. (Sze), 23.08
Attól nem lesz a kliens vastag, hogy UX, vagy terheléscsökkentés stb miatt alkalmazás-specifikus logika van a kliensen (is). A vékony és a vastag kliens ott válik el, hogy a vékony kliens működéséhez szükséges a szerver folyamatos jelenléte, a vastag kliens viszont kapcsolat nélkül is képes ellátni a funkcióját, ha csak korlátozottan is. Például részeredmények átmeneti tárolásával, ami a kapcsolat létrejötte után elküldi a tárolt adatokat a szervernek feldolgozásra.

A concurrency kezelésben elég jók a DB-k, ez nagyon alapvető képességük kell legyen, és feladattól függően érdemes lehet rájuk bízni. Egy tipikus webalkalmazás is jellemzően ezt teszi. Ha a kliensnek csak DB kapcsolata van, akkor ezt érdemes viszont tároltakkal megtámogatni. A jogosultságkezelés is vállalható, viszont szintén kell tárolt logika a validációkra ott is. Nyilván, itt nem üzleti igényekre alakítható, üzleti entitásokkal dolgozó jogosultságkezelésről van szó.
8

Attól nem lesz a kliens

inf3rno · Okt. 15. (Cs), 19.05
Attól nem lesz a kliens vastag, hogy UX, vagy terheléscsökkentés stb miatt alkalmazás-specifikus logika van a kliensen (is). A vékony és a vastag kliens ott válik el, hogy a vékony kliens működéséhez szükséges a szerver folyamatos jelenléte, a vastag kliens viszont kapcsolat nélkül is képes ellátni a funkcióját, ha csak korlátozottan is. Például részeredmények átmeneti tárolásával, ami a kapcsolat létrejötte után elküldi a tárolt adatokat a szervernek feldolgozásra.


Aha, hát én is úgy gondoltam, hogy nem jó, amit mond. Ezek szerint az sem, amit én mondok. :-)

Ha már webes fórum, akkor itt érdemes megemlíteni, hogy már vannak offline meg online eventek: ref, szóval elvileg egy SPA-t is meg lehet írni így, a rendelkezésre álló nem éppen nagy tárhellyel, amit a localstorage vagy sessionstorage ad. ref Itt azért ennek van adatbiztonsági vonzata is, ugyanúgy, mint a cache fejléceknek, mert a nagy többség nem ügyel rá, és titkosítatlanul tárolja az adatokat a kliens gépén.

A concurrency kezelésben elég jók a DB-k, ez nagyon alapvető képességük kell legyen, és feladattól függően érdemes lehet rájuk bízni. Egy tipikus webalkalmazás is jellemzően ezt teszi. Ha a kliensnek csak DB kapcsolata van, akkor ezt érdemes viszont tároltakkal megtámogatni. A jogosultságkezelés is vállalható, viszont szintén kell tárolt logika a validációkra ott is. Nyilván, itt nem üzleti igényekre alakítható, üzleti entitásokkal dolgozó jogosultságkezelésről van szó.


Igen, ez világos, de nagyon fapados lenne egy ilyen jogosultság kezelés, ami DB felhasználó alapú, már ha erre gondolsz. Igazából sosem csináltam ilyet, csak így belegondolva nem tűnik túl előnyösnek ahhoz képest, ha alkalmazás specifikusan programozzuk le. Nem látom továbbra sem az előnyét ennek a megközelítésnek, csak a hátrányait.
9

Ahol szofisztikáltabb

BlaZe · Okt. 16. (P), 00.33
Ahol szofisztikáltabb userkezelés kell, ott meg lehet írni azt is tároltban. Igazából egy modern RDBMS elég sokmindent tud, és szinte bármit meg lehet írni benne. Hogy érdemes-e, az már más kérdés :) Ahol semmi más szerepe nem lenne a szerveroldalnak, csak hogy átpasszolja az RDBMS-nek az adatokat, vagy ahol a logika nagy része sok rekorddal dolgozik, amiket nem lenne jó kimozgatni a DB-ből csak a feldolgozás kedvéért, ott ki lehet hagyni, és be lehet tenni az RDBMS-be az egészet. De bevallom én se erre indulnék, ha nem nagyon muszáj :)
12

Én ha nagyon muszáj, akkor

inf3rno · Okt. 16. (P), 03.03
Én ha nagyon muszáj, akkor se. :D