Most az a divat, hogy json mániás mindenki és nyomjuk oda a kilensre az összes lekérdezhető adatot (nyilván API-n keresztül - ez is hype része nyilván) aztán majd jönnek a százhúszor újra ugráló betöltő oldalak meg a cpu pörgető oldalak. Nem vagyok fejlődés ellenes meg alu sapka fóliás, de úgy érzem ez teljesen felesleges és ezálltal csak "termeljük" a react és angular "mérnök" urakat. Nem, nem vagyok ez ellen sem, csak egyszerűen úgy látszik boomer vagyok és nem látom benne a truvájt. Plusz egy réteg és az hogy manapság a kliensere tolunk mindent amiből amúgy több van mint szerver, akkor pláne nem meggyőző számomra. Utálom a (mobilon is) "ugráló oldalakat amik szarul vannak megírva, vagy hogy pörög a cpu egy sima oldal esetében mert csillió framework akármi töltődik be. Az külön klassz (nem) szerintem, hogy egy alap ilyen frontend több ezer file-ból (is) áll(hat).
Most egyébként mindezt azért írtam, mert véletlenül bele futottam ebbe -> https://astro.build/ és lehet, hogy ez tetszik :)
Mi a véleményetek?
- mgabor blogja
- A hozzászóláshoz be kell jelentkezni
- 665 megtekintés
Hozzászólások
jQuery-nél többre senkinek sincs szüksége.
- A hozzászóláshoz be kell jelentkezni
640kB mindenre elég
- A hozzászóláshoz be kell jelentkezni
Én azt érzem, hogy régebben PHP-ban beledobtam mindent IS, 1-2 JS megoldással, CSS stb... és használható lett az alkalmazás. Lehet nem áttünéses, csilli-villi, stb..., de használható és mellesleg nagyon gyors egy kenyérpiritón is.
Erre jönnek ezek a csoda framework-ök, amik bemutató alapján ígérnek sok szép jó dolgot, de a programozó a 20%-ról sem tudja mi hogyan működik. Csak LEGO-zik vele. Majd amikor valami nem egy akkor jönnek a hetekig tartó hibakeresések.
JSON API megoldásokkal lehet átadni sok sok adatot is, majd a frontend szür meg minden. De lehet úgy is, hogy már a backend szür, a frontend végülis csak egy dashboard lesz, ami a csúnya JSON API-s kommunikációkat fordítja le emberi kinézetre, hogy az egyszeri user tudja azokat használni.
A hiper szuper framework megoldássokkal jön az erőforrás pazarlás is. Egyszer csak azt veszed észre hogy egy régebbi i3-as már felfőzi a vizet miközben nyitva a lap. A programozó meg csak annyit mond rá hogy jobb gép kell alá, hogy kilistázzon egy 1000-elemes táblázatot valami, néha frissítve az adatokat.
Néha úgy vagyok, hogy a programozást onnan kellene tanítani, hogy mikrovezérlők, azt is Assembly-ben. Majd ott C-ben később. Csak, hogy érezze már a programozó, hogy mi az az pl. 1 MB és 10 MHz, ne csak dobálózzon vele hogy kevés a RAM a gépben, vagy gyenge a CPU.
- A hozzászóláshoz be kell jelentkezni
Erre szoktam mondani, hogy manapság ha egy problémát meg tudsz úgy oldani, hogy _csak_ ezerszer lassabb, mint egy optimális megoldás lenne, akkor az egy teljesen jó megoldás. Feltéve, hogy skálázódási probléma nincsen.
- A hozzászóláshoz be kell jelentkezni
nyilván API-n keresztül - ez is hype része nyilván
Először talán meg kellene érteni az igényt erre, látni rendes architektúrákat is a szarok helyett és utána lehordani az egészet. Közel sem biztos, hogy azt az API-t csak webről hívják. Van olyan API-nk, amit hív nekünk frontend (UI Backend), másik backend, ügyfél (ki tudja mivel, nem is érdekes igazából). Egy másik API-hoz most kalapálnak frontendet, de egy időben felmerült, hogy egy desktop alkalmazásból is hívva lesz.
Plusz, ha összegyógyítod a frontended a backend logikáddal, sokkal nehezebb egyik vagy másik komponenst cserélni vagy új változatot készíteni belőle. Vagy esetenként semmi köze a kettőnek egymáshoz. Pl. ott van egy útvonaltervező alkalmazás (pl. MÁV app, BKK futár, stb.), minek csinálni neki két külön implementációt, egyik ami a mobilos klienst szolgálja ki, másik ami meg a weboldalt, mikor egy API is elég neki?
És akkor a tesztelés részéről még mindig nem beszéltem. Sokkal egyszerűbb és tesztelhetőbb egy API-n keresztül egy szolgáltatás. A Single Responsible Principle itt is megállja a helyét a SOLID elvekből.
Nyilván vannak, ahol túlhasználás az egész, de nekem nagyon úgy tűnik a posztodból, hogy nem értetted meg, hogy mi volt az az igény, ami életre hívta ezt, csak a szar JS-es példákat láttad. Nem csak fosul megírt weboldalak léteznek, hanem alkalmazások is, amik át lettek költöztetve webre, mobilra, tabletre.
- A hozzászóláshoz be kell jelentkezni
> Van olyan API-nk, amit hív nekünk frontend (UI Backend), másik backend, ügyfél (ki tudja mivel, nem is érdekes igazából).
Tökéletes példa egy rossz architektúrára. Amikor az ügyfél kér valamit, ami API változással jár és tör mindent amit használja, milliószor láttam már ilyet.
> Plusz, ha összegyógyítod a frontended a backend logikáddal, sokkal nehezebb egyik vagy másik komponenst cserélni vagy új változatot készíteni belőle.
Á, a szokásos érv, a frontend-backend “szétválasztás”. Ha képes vagy normálisan modularizálni az alkalmazást, akkor nem lesz nehezebb semmit sem cserélni, ennek semmi köze a “frontendhez” és “backendhez”. Ha pedig a SOLID-al példálózól ennél, akkor bocs, de nem érted a SOLID elveket.
- A hozzászóláshoz be kell jelentkezni
Tökéletes példa egy rossz architektúrára. Amikor az ügyfél kér valamit, ami API változással jár és tör mindent amit használja, milliószor láttam már ilyet.
Bevallom, ezt nem értem. Mármint sem a problémát nem látom, sem a megoldási javaslatodat rá. Mi a különbség ilyen értelemben a külső és belső igény között? Vagy ha egyszer prodban van egy API, soha többet nem fejlesztitek?
Az utolsó, ügyfeleknek kiajánlott API, amin dolgoztam, 10000+ ügyfelet szolgált ki. Azóta, ha minden igaz, ez már a harmadával több. Egyetlen breaking change sem volt az alatt az egy év alatt, amíg a projekten dolgoztam. Egyébként meg ha az ügyfélnek az igényei mellett pénze is van, akkor sok dolog megoldható. :)
- A hozzászóláshoz be kell jelentkezni
Tökéletes példa egy rossz architektúrára. Amikor az ügyfél kér valamit, ami API változással jár és tör mindent amit használja, milliószor láttam már ilyet.
Bocs, az éjjel már nem voltam egyértelmű: nem közvetlen hív egy backend API-t az ügyfél. Amire rá akartam világítani, hogy nem tudhatod, hogy végeredményben ki fogja használni az API-d eredményét.
Á, a szokásos érv, a frontend-backend “szétválasztás”. Ha képes vagy normálisan modularizálni az alkalmazást, akkor nem lesz nehezebb semmit sem cserélni, ennek semmi köze a “frontendhez” és “backendhez”. Ha pedig a SOLID-al példálózól ennél, akkor bocs, de nem érted a SOLID elveket.
Leszámítva a skálázást vagy, hogy miért kezel ugyanaz a service olyan adatokat, ami csak a frontendnek kell vagy csak a backendnek, stb. Másrészt ha pl. kezdesz egy tök új frontendet nulláról, mi az istenért kellene összecsomagolni egy csomó más dologgal? Persze, nem állítom, hogy mindenhol szükség van egy microservice architektúrára, csináltam én is olyat, ahol egyben van minden, mert elég pici az egész ahhoz, de kicsit komolyabb alkalmazásnál már jobb a békesség. Főleg, ha nem is egy csapat fejleszti az egyes komponenseket.
- A hozzászóláshoz be kell jelentkezni
Hogy teljes legyen a kép, van egy olyan vonal is már, hogy frontend oldalon is darabolnak:
- A hozzászóláshoz be kell jelentkezni
Újrafeltalálta a kereket iframet.
- A hozzászóláshoz be kell jelentkezni
Az iframe-et egyébként tényleg fel lehetne újra találni, mert azért van vele probléma, inkább az az elgondolkodtató, hogy ~10 éve pont így csináltuk Silverlight-ban a UI elemeket, csak akkor még nem tudtuk, hogy ennek microfrontend a neve. :)
- A hozzászóláshoz be kell jelentkezni
Voltak egykor portletnek nevezett komponensek is, vagy húsz éve csinálnom is kellett olyat. Azon keresztül épült be a program egy nagyobb portálba. Úgy emlékszem, azt a szerver gyártotta le. Meg ami az iframeben megjelent, azt is.
Itt ha jól értem, a böngésző konstruálja meg a deklarációkból és runtime adatbeillesztésekből a renderelendő markupot.
Inkább az ebben a potenciál, hogy a megjelenítő eszköz elég erős hogy bármit is megcsináljon, a backend csak gyűjtse össze az adatokat, végezze el az üzleti logikát, a prezentációt engedje el, majd a rá csatlakozó eszközök azt megcsinálják a saját adottságainak megfelelően.
- A hozzászóláshoz be kell jelentkezni
Hihetetlen, hogy hol tart a tudomány... Ha az alkalmazás minden egyes kontrollja egy külön mikroszerviz, az nagyon jó mert végtelenül el lehet bonyolítani a release folyamatát is például. Ami eddig egy szkript volt az most már két-három mérnök folyamatos munkája lesz :-)
- A hozzászóláshoz be kell jelentkezni
Nem tudom, mennyire microservice ez valójában... Még Winforms alkalmazáshoz is gyártottunk külön UI komponenseket, saját logikával. De gyakorlatilag a GUI megjelenése óta létezik a widgetek mindenféle koncepciója, nincs ebben semmi új.
nagyon jó mert végtelenül el lehet bonyolítani a release folyamatát is például. Ami eddig egy szkript volt az most már két-három mérnök folyamatos munkája lesz :-)
Én nem tudom, nálatok mi a release folyamat, de nem értem, hogy ez hogy jött ki neked. Mitől lenne bonyolultabb? Ez is "csak" egy script, már ha script = normálisan kiépített CI/CD folyamat.
- A hozzászóláshoz be kell jelentkezni
Kivételesen belenéztem a linkbe, és van benne rajz arról, hogy minden mikrofrontendnek külön repója van. Tehát ki kell keresgetni, hogy melyikek az összetartozó verziók, amik hajlandóak együttműködni, ezzel kezdődik a munka. Gondolom mindenféle leírókból össze kell vadászni, vagy ilyesmi.
Bónusz kérdés: egy tavaly szeptemberi hibajegyhez társítsuk, hogy éppen melyik verzió futott a szerveren akkor. Mármint melyik mikrokomponensnek a melyik verziója? Mindegyiknek.
Ezzel szemben egyetlen repóban fejlesztve, ha valami rá van kommittoltva a masterre, akkor annak illene egyben működni. Ha kapott verzió taget, akkor pláne.
- A hozzászóláshoz be kell jelentkezni
van benne rajz arról, hogy minden mikrofrontendnek külön repója van. Tehát ki kell keresgetni, hogy melyikek az összetartozó verziók, amik hajlandóak együttműködni
Mindkét állítás igaz, de nincs köztük összefüggés. :)
Ha ömlesztve van az egész, akkor is figyelni kell arra, hogy ha te megcsinálsz X widgetet, ami Y helyről szedi az adatokat, akkor koordinálni kell az X és Y fejlesztőknek arról, hogy mikor mi mehet a trunkba. Nyilván ahol <5 fejlesztő van az egész termékre, ott ez könnyebb, de ez csalóka, mert ami egy kis csapatnál jó megoldásnak tűnik, az semennyire nem skálázható.
Ha viszont a komponensek külön csomagként készülnek el, akkor én csak berakom a függőségek közé, hogy "BizbaszWidget": "^1.5.0", és onnantól ~semmi dolgom vele, mert a CI/CD azt fogja behúzni, ami ennejk megfelel. Ha közben a BizbaszWidgetből kijön egy breaking change, azt majd alkalomadtán megnézem, és ha úgy döntök, beengedem a saját komponensembe. (Ehhez egyébként nem kell külön repo, bár az átláthatóságon sokat javítana.)
Bónusz kérdés: egy tavaly szeptemberi hibajegyhez társítsuk, hogy éppen melyik verzió futott a szerveren akkor. Mármint melyik mikrokomponensnek a melyik verziója? Mindegyiknek.
Szerintem ez relatíve értelmes CI/CD stratégia mellett nagyon egyszerűen megválaszolható.
Ezzel szemben egyetlen repóban fejlesztve, ha valami rá van kommittoltva a masterre, akkor annak illene egyben működni.
Ja, hát erről írtam fentebb, hogy ilyenkor jön az, hogy Józsi fejlesztett valamit, ami Béla fejlesztésére vár, ezért Józsi addig a saját feature branch-én tartja a változtatást, aztán majd beszélgetnek, hogy kinél mikor mehet a merge, és gyakorlatilag a teljes melót, amit a csomagkezelők ellátnak azt kiszervezted a hús-vér embereknek. :)
- A hozzászóláshoz be kell jelentkezni
>onnantól ~semmi dolgom vele, mert a CI/CD azt fogja behúzni, ami ennejk megfelel
>Szerintem ez relatíve értelmes CI/CD stratégia mellett nagyon egyszerűen megválaszolható.
Pontosan. És aki ezt a CI/CD-t és értelmes stratégiát megcsinálja és karbantartja, az lesz az a 2-3 mérnök, amit említettem fentebb :-)
>és gyakorlatilag a teljes melót, amit a csomagkezelők ellátnak azt kiszervezted a hús-vér embereknek.
Amit eleve is emberek csinálnak, hiszen:
* Ahhoz, hogy megcsináljanak egy API változást, mindkét oldalnak tudnia kell róla
* Ahhoz, hogy Józsi ki tudja egyáltalán próbálni, hogy amit csinált az működőképes, ahhoz szüksége van Béla fejlesztésére. Tehát a branch-re Béla már felrakta és ezt megbeszélték. (Persze Józsi fejleszthetne mock implementáció ellenében is, de legalább egy integrációs próbát csináljon már mielőtt release-eli a feature-t)
* Miután Józsi befejezte a munkáját minden pontosan úgy van a fejlesztői ágán, ahogy ki is kell releaselni, ezért ésszerű, ha a merge a release.
>ami egy kis csapatnál jó megoldásnak tűnik, az semennyire nem skálázható.
Ha meg nem kezdünk el triviális dolgokat is skálázhatóvá tervezni, akkor talán elég lesz a kis csapat a célt elérni :-)
- A hozzászóláshoz be kell jelentkezni
aki ezt a CI/CD-t és értelmes stratégiát megcsinálja és karbantartja, az lesz az a 2-3 mérnök
Ne szórakozzunk már, a saját hobbiprojektemben ezek a dolgok simán működnek, 2-3 mérnök nélkül is. Amúgy meg projektméret függő, ha 200 ember dolgozik a terméken, akkor tök normális a 2-3 ember, még kevés is, ha a teljes SDLC náluk van.
Ha meg nem kezdünk el triviális dolgokat is skálázhatóvá tervezni, akkor talán elég lesz a kis csapat a célt elérni :-)
Mondom, termékfüggő. Neked hány fejlesztő volt eddig a rekord, akivel ugyanazon a projekten dolgoztál? A rend kedvéért, nálam ez a szám ~800 fő. Ez csak a fejlesztők! Nem az egész cég.
- A hozzászóláshoz be kell jelentkezni
A kedvencem amikor a lyutyúb ezt csinálja:
- link megnyit új ablakban
- videó elkezd lejátszani, látszólag jól
- pár másodperc után rájön hogy hopp, kuki-gondjai vannak
- videó megszakad, popup feljön
- oké, rendben, minden, "ez így istenbiza legális" adatgyűjtésbe belegyezünk
- oldal újratölt
- ajánlott videók megváltoznak
- reklám
- reklám lemegy, utána videó elkezd lejátszani, jóesetben most már rendesen
Biztos nagyon sok frontendes együttes munkája hogy ez így ennyire hatékonytalan flottul megy!
- A hozzászóláshoz be kell jelentkezni
A react, vue, svelte, angular (ez utobbi tenyleg nagyon fos, erre nem ervenyes. Aki probalja eloadni, hogy biztos az Angular 1-et szidom mikor az Angular 2 jo, nem veszi eszre, hogy van mar Angular 8 is, amit o is okkal nem hasznal) elonyei csapatmunkaban jonnek elo. Amikor mar 5-10-20 frontendes van es kell valami rendszer, mert kaosz lesz, ha mindenki random rendszertelenul okadja a listenereket .classname-ekre es hasonlokra. Multihoz valo: kis reszteruleteknek megvan a szakertoje, senki nem ert pontosan mindent, csak elfogadja, hogy par dolog amit mas irt, az mukodik, viszont nem is kurjak szet a devek egymas mukodo kodjat olyan konnyen, stb.
Egyedul dolgozva viszont minden framework nelkul (vanilla JS) sokkal jobban lehet haladni es jobban is lehet tanulni, erted is, hogy mit csinalsz. Mar JQuery sem kell, 10-bol 9 JQuery feature-nek lett Vanilla JS megoldasa ami minden ujabb bongeszovel kompatibilis. A tizedik kiveteleset meg pont jo learning curve megirni a JQuery helyett - foleg nemlatszo, kesobb megjeleniteni tervezett DOM elemek manipulalasakor lehet rengeteget tanulni.
Szereny velemenyem szerint meg a TypeScript is csak akkor es csak azert kell, hogy mas dev ne tudja szetkurni a tipusaidat. Ha megtanulod elegge a Vanilla JS-t alazattal, akkor az egyszemelyes/egyfrontendes projektjeidre az sem kell.
- A hozzászóláshoz be kell jelentkezni