Angular frontend, ??? backend

Internet: PHP, CGI, stb.

Sziasztok!

Nálam tapasztaltabbak segítségét, tanácsát, véleményét szeretném kérni.

Egy nagyobb projekt elején járok, van némi előéletem a webprogramozásban, viszont ez meglehetősen régi, és évekkel ezelőtt is csak autodidakta módon sajátítottam el, amire szükségem volt. (html, css, php, mysql)

A mostani feladat egy olyan weboldal lenne, ami kezdetben kb. 500 felhasználót szolgálna ki (később ez a szám több 10 ezerre is nőhet). A fő feladatok statisztikák tárolása és néhány kimutatás készítése, mellett egy olyan rendszer lenne, ami sportbajnokságok és kupák sorsolásának generálásával, lebonyolításával és nyomonkövetésével foglalkozna. Játékosok, csapatok és a korábban említett események menedzselése mellett. Nem akartalak titeket sok felesleges infóval traktálni, de hátha hasznos lesz az előzőekből néhány.

A technológia választásnál úgy voltam vele, ha már lúd legyen kövér, ezért esett a választásom az Angularra, viszont nem tudom bemerjek-e vállalni egy másik számomra teljesen új technológiát szerver oldalról is. Ti mit tanácsoltok, vágjak bele nodejs-el, vagy a már korábbról ismert php+mysql vonalat is előszedhetem? (Bármilyen pro és kontra érv érdekel, nyitott vagyok gyakorlatilag bármire.) Olvastam a MEAN-ről, de az már lehet túl nagy falat lenne hiszen mindegyik elemében újoncnak számítok.

Üdv,
Hirannad

  • 4182 megtekintés

( sfeher v | 2018. 04. 30., h – 19:19 )

Hello,

A feladat komplexitasat Te ismered, de én mondjuk olyan stack-el állnék neki amit ismerek legalább valamennyire. 10000 usernel már a skálázhatósaggal is kell majd foglakoznod. Így érdemes ezt is figyelembe venned a választásnál. A megvalósításhoz mennyi idő áll rendelkezésre? Ha sok (nincs céldátum, hobbyproject, te vagy a főnök stb. ) akkor valaszhatsz hosszabb tanulási görbéjű megoldást. Ha addott határidőre kész kell lennie, akkor bevált, ismert technológiát választanék.

( carlcolt | 2018. 04. 30., h – 19:23 )

PHP Postgresql jo lesz neked, vagy ha nagyon ragaszkodsz a mysql-hez, hasznald azt. PHP olyan amilyen, de legalabb algoritmikus es 10000 usernel nem jonnek meg elo a hatranyai

NodeJS-t felejtsd el: meg kell tanulnod hozza egy felesleges es rossz gondolkodasi stilust

Meg en az Angulart is atgondolnam. Mit nem tudsz vanilla JS-sel, esetleg JQuery-vel megcsinalni, amit Angularral igen? Inkabb tanuld meg rendesen hasznalni a "sima JS-t". Az Angular egy rakas hulladek, es a verziozasi politikaja miatt egy idozitett bomba az osszes npm-es dependency-jevel egyutt.

Postgresql miért lenne jobb? Milyen előnyei vannak a mysqlel szemben?

Ahogy olvastam elég megosztó a közösség node és társa téren, miért van ez?

Az Angular egy rakas hulladek, es a verziozasi politikaja miatt egy idozitett bomba az osszes npm-es dependency-jevel egyutt.
Ezt kifejtenéd, mint mondtam nem vagyok a legnaprakészebb a témában?! :D

“Ahogy olvastam elég megosztó a közösség node és társa téren, miért van ez?“

Mint a kozeletben, ugyanugy megvan a hype es a fika vagon is. Egyik sem okos, hisz minden eszkoznek megvan a maga helye.

Aki pedig ezt nem latja, az nem racionalis dontest hoz egy projekt tervezesi fazisaban, hanem erzelmit. Fuggetlenul hogy pozitivba vagy negativba dol az eredmeny.

Js alapu runtime/fw/libek (es nosql) tipikusan a prototipusu projekteknel mukodnek jol, ahol a spec dinamikusan rovid idon belul valtozik.

Teljesitmennyel meg akkor foglalkozol, amikor ennek megvan az uzleti oldalrol is megtamasztott igenye, es nem pusztan 2ms egy string manipulacio eseten.

( r3flow | 2018. 04. 30., h – 20:09 )

Nem vagyok webfejlesztő (még, de sokféle nyelven írtam/üzemeltettem már sokféle szoftvert), de elkezdtem belemerülni (olvasgatni) egy kicsit, saját részre, egyszerű dolgok megvalósításához. Amikor ez a téma felmerült akkor épp az Angular jött szembe és elsőre nagyon tetszett. Aztán olvasgattam, aztán már nem volt olyan fényes, megnéztem a többit is. Elsőre mindegyik tetszett, de aztán mégsem. :-D (a tett halála az olvasás) Most, ma, jelen állapot szerint ha eljön a napja, hogy elkezdjem az első projektet, akkor kliens oldalon semmit vagy Vue.js-t, backend oldalon sok olvasás után (pythontól a ruston át a java EE-n túl a jövőhétig) úgy döntöttem Go-t fogok használni. Majd, ha odajutok. Egyelőre a sima JS-t tanulgatom... egyre csökkenő lelkesedéssel... :-D

( sz332 v | 2018. 04. 30., h – 21:43 )

Vegyetek fel egy olyat, akinek van ebben tapasztalata, de tényleg. Egyébként tök mindegy a frontend technológia,
vue, polymer, angular, react, stb. mindegyikkel meg tudjátok csinálni, és eléggé hasonlóak.

Backend-re olyat válassz, amit már ismersz, egyértelműen, főleg, ha szűkös a határidő. Ha majd korlátokba ütköztök,
akkor átírjátok. Csinálj egy normális REST interface-t, ezt írd le valamilyen leíró nyelvvel (raml, swagger) abból
le tudod generáltatni a keretet, és utána írd meg az üzleti logikát. Igazából ennyi.

( winben | 2018. 05. 01., k – 10:32 )

A jelenlegi angular eléggé lassú, sokan az 1-es verzióra eszküsznek még mindig.
Ha nem ragaszkodsz az angularhoz és nem kap el egy hányinger a JSX-től akkor nézz rá a preact-ra. Elég ígéretesnek tűnik nekem.

( andrewjsi | 2018. 05. 01., k – 11:16 )

use Modern::Perl;

Nálunk webalkalmazás területen szerver oldalon minden tekintetben a Mojolicious + PostgreSQL vált be hosszú távon. Ehhez persze az kell, hogy az ember értse és szeresse a Perl-t, ami manapság ritkaságnak számít. A backend munka a legnagyobb nyugalomban, szépen fokozatosan építkezve zajlik.

Nem ennyire nyugis a frontend rész. A Javascript világ egy igazi mocsár, amibe könnyű elsüllyedni és csak későn veszed észre, hogy felemésztett a dependency hell, mert kénytelen vagy 19 féle keretrendszert és más libet használni ahhoz, hogy egy táblázat elemeit a megfelelő módon jeleníts meg a böngészőben. Ebben az esetben jól jön, ha van egy ilyen hardvereszközöd:) Ez igaz a javascript backendre is szerver oldalon, ezért ahogy a kolléga is említette, messziről kerüld a NodeJS-t!

A frontendezést az AngularJS-el kezdtük (1.x.x verzió) és még mindig ezt használjuk, de már megvan az alternatíva. Azért az AngularJS-re esett a választás, mert megtetszett a two-way-binding, és az, hogy a többiekhez képest kevés JS kódot kell firkálni ahhoz, hogy elinduljon a rendszer. Ugyanis nálunk az a koncepció, hogy kliens oldalon, azaz frontenden minél kevesebb JS kódot használjunk. A JS-t csak megjelenítésre, a szerverrel való kommunikációra és ilyen alapszintű dolgokra használjuk. Például semmilyen animációra nem használunk JS-t, mert arra ott van a CSS transition.

Pár éve, amikor kijött az Angular 2-es verziója, akkor elkezdtek noszogatni, hogy ideje váltani, stb. Próbáltam kacérkodni vele, de valahogy annyira eltért az egész koncepciója az 1-es AngularJS-től, hogy nem. Persze akkoriban a csapból is az a hype folyt, hogy váltani kell, de nem adtuk be a derekunkat - így utólag nagyon helyesen.

Szóval az AngularJS és az Angular az két különböző dolog. AngularJS-nek hívják az 1.x.x verziót, és Angular-nak a 2, 3, 4, 5, stb. verziót. Az AngularJS most épp az 1.6.x verziónál jár. Az 1.5-ös verzióba bekerült a komponens kezelés, ami jó dolog, bár elég undormány lett az API-ja. Állítólag még egy fő verzió kiadással jelentkezik idén, aztán 3 évig biztonsági karbantartás lesz. Erről itt írnak. Az Angular 2-nek csupán marketing okokból lett Angular a neve, mert közben elkezdett erősödni a React, és hát valamit vakarózni kellett ugye.

Miközben tombol(t) a hype az Angular és a React környékén, és aki ezekbe belekerült, az megtapasztalta milyen az, amikor havonta jönnek ki főverziók és API változtatások. Ennek az őrületnek mondott nemet egy fiatal programozó, és miután megjárta az AngularJS, Angular, React bugyrokat, megalkotta a számára elfogadható reaktív keretrendszert. Ez lett a Vue.

Frontend oldalra szívből ajánlom a Vue-t. A dokumentációja zseniális. AngularJS múlttal ezen a ponton javaslom a doksi elkezdését. A Vue a legtöbb problémánkra elemi szintű megoldást javasol, amivel kapcsolatban az AngularJS megszivatott. Érdemes áttanulmányozni, hogy miként lett levezényelve a Vue 1-ről Vue 2-re váltás, amikor változott az API. Sokan tanulhatnának belőle! Magam részéről már várom, hogy legyen kis időnk elhagyni az AngularJS-t, áttérni Vue-ra, hogy kliens oldalon is élvezhessük azt a nyugalmat és haladós munkavégzést, amit a Perl+Mojo+Postgres nyújt szerver oldalon:)

Először is szeretném nagyon megköszönni a terjedelmes véleménynyilvánítást, és segítséget!

Nem te vagy az első aki a perl elsajátítására bíztat, viszont nem tudom ha most kezdenék el ismerkedni vele, mennyivel hosszabbítaná meg a fejlesztési időt?

Igen a Vue után kutakodva arra lettem figyelmes, hogy a dokumentációja jóval kiforrottabb, mint amiket az angular tanulmányozása során találtam.

Bár az Angularról sikerült lebeszélnetek a backend picit még megint kérdőjeles. PHP és mysql, vagy Perl és postgresql. Az előbbi mellett egyenlőre csak a korábbi ismereteim szólnak.

+1 a vue-ra. Nálunk a frontendes srácok sok frameworkot kipróbáltak, de ettől nem hányták el magukat 5 perc alatt. Sőt, kedvelik :)

Backendre meg spring-boot + Kotlin. Én speciel nagyon nem szeretem a spring-et, de nem vitatom el az előnyeit, Kotlin-al meg már nem fáj jvm-re fejleszteni.
Adatbázisnak meg mongo vagy hasonló, RDBMS-eket inkább kerülném mostanában.

Nem "tobb", hanem "mas".

Pl azert, hogy 1000 helyett 100 000 iras mehessen masodpercenkent, lemondasz arrol, hogy 3 oszlopnal tobbon legyen index es foreign key-eid lehessenek, es arrol is lemondasz, hogy eselyes legyen index nelkuli oszlopon gyorsan keresni. Ilyesmiket kell elkepzelni.

Akkor peldak:

PostgreSQL mindenben gyorsabb es eroforrasbaratabb MongoDB-nel, kivetel nehany geometriai algoritmust es a rw horizontalis skalazhatosagot. Ez utobbi akkor jo, ha valami olyat irsz surun, aminel semmihez nem kell hozzanezni a komzisztenciat es semmi szuperglobalis unique key nincs. Az egyetlen eletkepes pelda amit erre tudok mondani: "logolas". Na, arra alkalmasabb a hadoop peldaul, az meg tobbet tud irni.

Ellenben ismert gyengeje a MongoDB-nek az elfogyo memorian es az eroforrasigenyen kivul: az elso circular reference utan lotto, hogy ki hogy alakitotta a semat, sok rossz megoldas kozul lehet valasztani.

Masik pelda: solr/elasticsearch: pontszamos kereseshez konnyebb es gyorsabb megoldas, mint (materialised) view-kkal szorakozni egy RDBMS-ben.

Maga a NoSQL teves elnevezes egyebkent, egyre tobb "NoSQL"-t lehet SQL-szeru/SQL alapu nyelvvel query-zni, csak pl meglepodsz ha nem ismeri a "GROUP BY"-t ugy egyaltalan, vagy ismeri, de csak nyers oszlopertekeken, nem aritmetikai es logikai kifejezeseken, regexp returnokon. A helyes megnevezes nonRDBMS lenne, azaz "nemrelacios adatbazisok" a NoSQL helyett.

Es ami meg szomoru, hogy sokszor ez az iparag is a hype-rol szol (megint a MongoDB-re mutogatok, ok probalnak feature set helyett marketinggel kompenzalni). Marpedig ez az az iparag, aminek nem hype-rol, hanem edge case-ekrol, tesztesetekrol kene szolnia.

Bizony, Postgresnél nagyon jól kitalálták a jsonb típust. SELECT-nél bele lehet "nyilazni" a JSON mezőkbe, WHERE kifejezésben is remekül használható. Lehet INDEXelni, CONSTRAINT-et tenni tetszőleges mélységű JSON mezőkre. Van egy csomó JSON specifikus beépített függvény. Egyetlen egy SQL parancsban megfogalmazva lehet módosítani bármelyik JSON tagot, összefűzni őket, két JSON mező különbségét venni és lekérni egy harmadik JSON-be, stb, stb. Ha még hozzáképzeljük a tranzakciókat és a mező zárolást, akkor már szinte mindenünk megvan:) De akinek ezek nem kellenek, az megelégedhet csupán az INSERT és SELECT-el, mert nagyon gyors. Évek óta (asszem 9.3 óta) használjuk és erőteljesen támaszkodunk rá éles környezetben. Nem fog kiakadni memória hiányra, mint a Mongo:)

( Hirannad | 2018. 05. 01., k – 18:04 )

vue cli-vel kezdhetem szerintetek, a későbbiekben fontos lesz a skálázhatóság?!

Úgy néz ki maradok a PHP-mysql kombónál így kisebb fába vágom a fejszémet, illetve ahhoz találtam már a regisztrációhoz is elég jól összeszedett leírást egy helyen, nem különböző forrásokból kell majd összeollóznom az egészet, ha jól gondolom.
(itt: https://www.phpclasses.org/blog/package/10087/post/1-secure-login-and-r…)

Laravelről valakinek vélemény?

Szerintem az ilyen egyedi libraryket felejtsd el. Valassz egy nepszeru frameworkot, amihez talalsz jol bevalt regisztracios kiegeszitot. Lehetoleg olyat, ami folyamatosan karban van tartva, konnyen ki lehet egesziteni. PHP vonalon laravel, symfony, stb teljesen mindegy. Amelyik szimpatikus neked. Ugyanez igaz a tobbi nyelvre is. A framework nelkuli fejlesztes biztonsagi, karbantarthatosagi es mas egyeb problemakhoz vezet. A framework dokumentaciot pedig vedd komolyan az egyedi otletekkel szemben, kulonben egy nagy kaosz lesz a vege.

ORM gyarilag van benne, ez kifejezetten szimpatikus. Routing teruleten szerintem szebb (bar ez izles dolga) a Laravel megoldasa, olyan middelware reteget (van gyari Auth, esetleg ott a Laravel Passport, ha API authot akarsz) teszel a dolgok ele, ami jolesik. Nagyobb a tamogatottsaga (pl: Laracast altal), CI-vel kapcsolatosan nem ismerek ilyen portalt (igaz, utana sem neztem). Nekem az a tapasztalatom, hogy a Laravel rugalmasabb, mint a CI (CI-vel utoljara 2013-ban dolgoztam, Laravelt ~4 eve hasznalok).

( uid_4263 v | 2018. 05. 01., k – 18:41 )

Olyan technológiát válassz amivel már tudsz érdemi munkát végezni, különben borítékolható a katasztrófa. Hacsak nem vagy valami szuperhős. :) Amúgy 0day-től kezdve amazonoznék, van olcsóság meg van free tier, és könnyen fel tudod skálázni nagy terhelésre. Adnak adatbázist is, amit ők managelnek, neked csak használni meg terhelni kell.

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

( Hirannad | 2018. 05. 03., cs – 20:16 )

Nem lenne valaki a mentorom, csak néha kellene egy kis mankó?! :D

A projekt is érdekes, és elég összetett, illetve újdonságnak számít idehaza, szóval jó tapasztalat szerzés lehet akár egy tapasztaltabb programozónak is.

Apróságokon bukok el, valószínűleg a kezdő löket hiányzik, hogy lendületet kapjak.

Ne haragudj, de nem bírtam megállni.

Megnyertem én is egy projektet, elég nagy, kellene egy kisebb házat építeni. Igaz eddig még csak a kisszobát
festettem ki fehérre, de hát gyorsan tanulok. Tudna valaki segíteni? Jó tapasztalatszerzés lehet akár egy
tapasztaltabb építőipari munkásnak is.

A mentorálás fogalma egyáltalán nem azonosítható az általad vázolt szituációval. Egy szóval sem mondtam, hogy nem Én szeretném elvégezni a feladatot. Szimplán iránymutatás, néha megerősítés, ha valami jó irányba tart esetleg figyelmeztetés, ha hibáztam, de pl. én tapasztalatlanságomból kifolyólag lehet sosem venném észre, vagy nem gondolnám, hogy arra is figyelnem kell.