Van egy projekt. Python + NodeJS + Angular mint tech stackről vélemények? 
12 hozzászólás
Ha legacy vagy rendszerközeli kód akkor érthető.. amúgy pedig nem látok nagyon olyan nyelv-specifikus dolgot amiért mindkettőt meg kéne tartani. Főeg, hogy az Angularnak úgy is mindegy milyen service-ket hív meg. Persze, ha ez csak egy hobby projekt akkor izgalmas lehet egy rendszerközeli automatizálás / legacy integráció (python) + emberibb servicek (nodeJS) + egységes UI implementáció (Angular). Persze ha real-time dolgokról van szó (és legacy) akkor igazából a python úgy is csak az adatbázissal beszél.. nem hiszem hogy effektív lenne ha a NodeJS direktbe Pythonból szippantaná át infokat egy kis extra latencyvel
Haszprus, Jó kérdés.. én kicsit maradi vagyok, de úgy vélem ha green field projektről beszélünk, én sose keverném a nyelveket microservice-knél sem.. ha pedig legacy, az azt jelenti hogy rengeteg régebbi dolgot kell átírni, ott sem erőltetném a többnyelvűséget hacsak valami nem indokolja. Pl. Egy valós dolog lehet ha tegyük fel van két cég, ami beszállít(ott) a rendszerbe anno, egyikük Javaban, másik Pythonban csinál mindent, microserviceknél szerencsére ez nem igazán számít. Vagy másik példa lehet ha bizonyos funkciókat jobb leimplementálni egy bizonyos nyelven (Windows services vs. .NET). De csak azért nem kevernék mondjuk egy ideális 7-8 fős projekt kompozíciót, mert
lehet. Óriáis overhead lehet hogy olyan Technical PM / Leadek legyenek velük akik mindkettőt átlátják.. ha pedig két különböző kell akkor csúnya nagy viták lesznek + sok extra pénzt felemészthet.
Mondjuk kíváncsi vagyok rá, lehet már több tecnhológia nyújt közvetlen service-ket pl. in-memory adatbázisok stb, amennyiben ezek natív interface-k biztosan elgondolkoznék hogy beilleszem őket az archtectúrába mindenféle driver nélkül hogy spóroljak a latency-vel.. itt meg persze a security a kérdés, de megfelelően átgondolot network architectúrával azon is lehet faragni. Habár ugye itt nem igazán nyelvekről van szó, de ez is előny hogy nem feltétlen múszáj centralizált megoldáson gondolkozni microservice-k esetén.
Ja! Újabb python már nem annyira. Fontos, hogy a szerveroldali frameworköd szeresse a latest interpretert is. Ha ezt nem szereti - valami oknál fogva pythonban ez meglepően gyakran valahogy nem szokás - akkor bukó van.
További don't forget: pythonban NINCS:
- rendes multithread support
- rendes garbage collection
Ezeknek a hiánya alapvetően közvetett következményekkel jár, melyek lényege az, hogy a legtöbb python framework bonyolultsága, képességei és teljesítménye elég közel jár a nyelv által engedett maximumhoz (értsd: nem szarok kifejezetten, de azért a hasonló java funkcionalitás mögött azért egyértelműen elmaradnak, és sokkal jobbra nem nagyon lehet már megírni őket).
Ha jvm alapú pythont használnál (google for jython), akkor ezek volnának, de ennyi mindent úgyse fogsz összelőni egyszerre.
Megfigyelésem szerint a python projekteknél jóval nagyobb a veszélye annak, hogy longterm is bugfix neverendingstoryba fullad a dolog. SOKKAL fontosabb hogy legyen rendes teszting, mint jávánál, ennek ellenére sokkal kevésbé szokás, hogy ténylegesen van is.
Ezeknek nem kellene így lennie. Php-t is lehetne jól csinálni, nem a nyelv hibája, hogy nem szokás.
De TE csinálhatod jól is, csak az nem lesz konform a tömegeknek. Sok mindentudó majomnak kell majd elmagyaráznod, hogy nem, nem te vagy a hülye, várja csak ki a végét. De ha a tömegiránytól lényegesen különböző irányokba is an kedved-merszed haladni, annak hosszú távon mindenképpen jelentős személyiségfejlesztő hatása lesz.
További don't forget: pythonban NINCS:
- rendes multithread support
- rendes garbage collection
Ezeknek a hiánya alapvetően közvetett következményekkel jár, melyek lényege az, hogy a legtöbb python framework bonyolultsága, képességei és teljesítménye elég közel jár a nyelv által engedett maximumhoz (értsd: nem szarok kifejezetten, de azért a hasonló java funkcionalitás mögött azért egyértelműen elmaradnak, és sokkal jobbra nem nagyon lehet már megírni őket).
Ha jvm alapú pythont használnál (google for jython), akkor ezek volnának, de ennyi mindent úgyse fogsz összelőni egyszerre.
Megfigyelésem szerint a python projekteknél jóval nagyobb a veszélye annak, hogy longterm is bugfix neverendingstoryba fullad a dolog. SOKKAL fontosabb hogy legyen rendes teszting, mint jávánál, ennek ellenére sokkal kevésbé szokás, hogy ténylegesen van is.
Ezeknek nem kellene így lennie. Php-t is lehetne jól csinálni, nem a nyelv hibája, hogy nem szokás.
De TE csinálhatod jól is, csak az nem lesz konform a tömegeknek. Sok mindentudó majomnak kell majd elmagyaráznod, hogy nem, nem te vagy a hülye, várja csak ki a végét. De ha a tömegiránytól lényegesen különböző irányokba is an kedved-merszed haladni, annak hosszú távon mindenképpen jelentős személyiségfejlesztő hatása lesz.
NodeJS-el kapcsolatban is hozzátenném, hogy szép és jó.. igazából újra feltalálták a spanyolviaszt (Java New I/O ugyebár, 2002), aminek azért komoly hátrányai is lehetnek:
- elég nehéz optimálisra belőni egy saját NodeJS production servert, mivel itt nem thread-ekben és tiszta terhelésben kell gondolkozni. Persze lehet a Heroku-ra mutogatni, hogy a dyno-k milyen szépen skálázódnak.. persze, csak legyen olyan cég, aki mosolyogva fizessen egy alul-optimizált app/framework miatt extra $X-t
- a másik probléma is ehhez kapcsolódik.. bár nagyon szép reklám, hogy legyen a back-end is olyan nyelven írva, mint a front-end.. ez egy nettó hülyeség. Amennyiben bárki használ még ma rengeteg pure Javascript kódot a UI-ban, akkor sincs sok köze egy NodeJS apphoz a szintaktikán kívül (amit azért meg lehet pár hét alatt szokni, még ha nem is vagy UI JS-es)
Persze, talán az event-driven gondolkodásmód közelebb áll egy UI JS dev-hez, de igazából, amikor én elolvastam pár NodeJS könyvet és ki is próbáltam.. hát azért jól átgondolni hogy is van ez a
NodeJS-nek az erőssége ha nagyon sok real-time adatot akarsz közvetíteni és ezt mindkét irányban. Akkor biztosan lehet ezzel spórolni is, bár akkor is lehet csak a kulcs-komponensnél használnám. Szóval meghazudtolom magam kicsit: ha van olyan funkció, amit csak egy bizonyos nyelv képes maximálisan megoldani, akkor persze lehet keverni a nyelveket. Szóval az egész appot nem hiszem hogy csak ezért megírnám JSben.
Én régimódi arcként fognék egy Spring 4-et, mellé AngularJS-t.. ha van bármilyen kritikus real-time cucc, akkor esetleg NodeJS (bár Spring 4 MVC tökéletesen támogatja a non-blocking I/O-t).
Főleg startup projekteknél érdemes tudni: ha valaha lesz acquistion és a product tele van egzotikus nyelvekkel.. annak ára lesz. Ugyanez érvényes a sikeres productra, amit évekig kell majd supportálni és mellé hajkurászni azokat a fejlesztőket (idővel olyan árban lesznek mint a Mainframe-esek
)
Ha hobby projekt akkor meg ezt ignoráld, jó ezekkel kísérletezni.. meg ki tudja mit hoz a jövő.
- elég nehéz optimálisra belőni egy saját NodeJS production servert, mivel itt nem thread-ekben és tiszta terhelésben kell gondolkozni. Persze lehet a Heroku-ra mutogatni, hogy a dyno-k milyen szépen skálázódnak.. persze, csak legyen olyan cég, aki mosolyogva fizessen egy alul-optimizált app/framework miatt extra $X-t
- a másik probléma is ehhez kapcsolódik.. bár nagyon szép reklám, hogy legyen a back-end is olyan nyelven írva, mint a front-end.. ez egy nettó hülyeség. Amennyiben bárki használ még ma rengeteg pure Javascript kódot a UI-ban, akkor sincs sok köze egy NodeJS apphoz a szintaktikán kívül (amit azért meg lehet pár hét alatt szokni, még ha nem is vagy UI JS-es)
Persze, talán az event-driven gondolkodásmód közelebb áll egy UI JS dev-hez, de igazából, amikor én elolvastam pár NodeJS könyvet és ki is próbáltam.. hát azért jól átgondolni hogy is van ez a
ne blockolj I/O-t, minden úgy történjen ahogy te azt kitaláltad, nem egyszerű. Teljesen más, mint egy átlagos PHP vagy Java back-end. Persze lehet különböző framework-ökeket használni, de hiába az aktív (bár viszonylag kicsi) community, nem sok embert láttam arról beszélni, hogy
na akkor én most megyek productionbe NodeJS appal. Ami nem véletlen.. persze egy-egy service-t lehet átírnak nagyobb cégek, kísérleteznek, de még mindig nem terjedt el igazán.
NodeJS-nek az erőssége ha nagyon sok real-time adatot akarsz közvetíteni és ezt mindkét irányban. Akkor biztosan lehet ezzel spórolni is, bár akkor is lehet csak a kulcs-komponensnél használnám. Szóval meghazudtolom magam kicsit: ha van olyan funkció, amit csak egy bizonyos nyelv képes maximálisan megoldani, akkor persze lehet keverni a nyelveket. Szóval az egész appot nem hiszem hogy csak ezért megírnám JSben.
Én régimódi arcként fognék egy Spring 4-et, mellé AngularJS-t.. ha van bármilyen kritikus real-time cucc, akkor esetleg NodeJS (bár Spring 4 MVC tökéletesen támogatja a non-blocking I/O-t).
Főleg startup projekteknél érdemes tudni: ha valaha lesz acquistion és a product tele van egzotikus nyelvekkel.. annak ára lesz. Ugyanez érvényes a sikeres productra, amit évekig kell majd supportálni és mellé hajkurászni azokat a fejlesztőket (idővel olyan árban lesznek mint a Mainframe-esek
)Ha hobby projekt akkor meg ezt ignoráld, jó ezekkel kísérletezni.. meg ki tudja mit hoz a jövő.
válasz
2 like
OFF
10 évvel a közzététele után került elém
Sporttalanság | árnyékos oldal
10 évvel a közzététele után került elém
Sporttalanságcímű írásod - amihez már nem lehet hozzászólni. Eddig úgy gondolhattam, hogy ez egy speciális érzés, de most már látom, hogy nem vagyok egyedül.
Sporttalanság | árnyékos oldal
Én azt gondolom, hogy a pythont és nodejs-t egyszerre használó projektek architectje 50% bor + 50% sör koktélt szeretne inni behányásig.
Drága jó 11-eském…
Maximálisan igazad van abban, hogy a fejlesztők, kollégák, későbbi kollégák szopatásán kívül a világon semmire nem jó egy ilyen kombó :-) Sőt még vicces is, úgyhogy egyáltalán nem gond, hogy ezt írtad, sőt.-)
Maximálisan igazad van abban is, hogy ha zavarna a lehetőség, hogy másvalaki esetleg újrahasznosítja a nickem, akkor inkább regisztrálnom kéne egyet… :-)
Ez mind igaz, másrészt viszont szerintem azért még jobb fejség lett volna, 3
Maximálisan igazad van abban, hogy a fejlesztők, kollégák, későbbi kollégák szopatásán kívül a világon semmire nem jó egy ilyen kombó :-) Sőt még vicces is, úgyhogy egyáltalán nem gond, hogy ezt írtad, sőt.-)
Maximálisan igazad van abban is, hogy ha zavarna a lehetőség, hogy másvalaki esetleg újrahasznosítja a nickem, akkor inkább regisztrálnom kéne egyet… :-)
Ez mind igaz, másrészt viszont szerintem azért még jobb fejség lett volna, 3
qnickű anonim hozzászólás alá, amiket nem írtál, nem teszel oda egy negyediket, amit viszont igen. :-)
