Jak mám programovat v Node.js?

[Zabanovaný Anonymní Troll]

Udelat necemu dobre design neni uplne jednoduche a v Jave je diky Springu zavedena uz 2 dekady metodologi toho, jak ma komponenta vypadat. Je to spravne a vhodne definovano tim frameworkem. Delat neco OOP uplne od nuly, tomu se snazim vyhybat, protoze to neni tak jednoduche - mam tendenci vsude uplatnovat to, jak vypada komponenta ve eSpringu, protoze je to prehledny a dobry design, tzn. rozdeleni na API, Service, DAO, domenovy model, vstupni mappery, vystupni mappery, background joby - na tom neni treba nic menit, nikdo nic lepsiho nez je tohle nevymysli.

Pokud se někdo pokusí použít metodologii Springu v NodeJS nebo třeba v PHP, tak je z toho obvykle katastrofální design aplikace plný mapperů a nesmyslných servisních tříd. Do MVC nic takového nepatří.

Co je spatneho na tom, mit design udelany tak, ze budu rozlisovat kategorie funkci na api, vstupni mappery, vystupni mapper, service, domenu, dao a background joby? Kazde kategorii bude i odpovidat jedna slozka. To mi vysvetli, co je na tom tak spatneho. - to ti prijde prebyrokratizovane?

Jaká jedna odpovídající složka? Copak ty složky pojmenováváš názvem kategorie? Správně mají být pojmenovány názvem domény, o kterou se starají. Zbytečně ti vzniká další vrstva adresářů. Struktura má být plochá, dvouvrstvá, maximálně třívrstvá. V žádném případě se z toho nesmí dělat taxonomie. Slova mapper, service, domain apod. do těch názvů nepatří - jinak z návrhu vznikne paskvil.

Videl jsem 2 zpusoby v praxi - slozky pojmenovane nazvem domeny o kterou se staraji a slozky s nazvem kategorie. Ta prvni varianta se vyskytovala v enviromentu kde se moc nedelalo OOP, architektura byla plocha. Ta druha varianta se pouzivala v enviromentu, kde se delalo OOP.

u me zatim vede v prehlednosti 2 varianta - slozky nesou nazev kategorie. Ale nic samozrejme neni tak jednoduche, aby to bylo cernobile - nekdy je vliv domeny (nebo spise subdomeny - nejakou domenu resi komponenta) natolik znacny, ze z hlediska prehlednosti je vhodne, aby mela svou vlastni slozku. (napr. authentikace)

Vzhledem k tomu ze komponenty by nemely byt monoliticke hydry, ale mely byt specializovane na neco, dava o to vice rozdeleni slozek dle kategorii smysl, protoze vsechny tridy jaksi resi vicemene jednu a tutez domenu, ktera je definovana prave tou komponentou samotnou.

Muzu mit slozku domain a v ni mit domenove objekty, protoze uz ten samotny domenovy model hodne napovida o tom, co vlastne ta komponenta bude delat, jake problematiky uloh resi.

[Reklama]

[Zabanovaný Anonymní Troll]

Nevim jak mam udelat spravny OOP desigm kdyz si jako jednu z prvnich veci neujasnim domenovy model. Me to tak vyhovuje.

Dobry OOP? picovina... https://sw-samuraj.cz/2019/02/remcani-proti-jave/

V tom blogu nepopisuje nic jiného, než blbě pochopené OOP. Java je v tom nevinně.

E: p.s. moja najbolúbenejšia kombinácia technológií je Node.js+Angular+Golang+Redis všetko cestou MVC ... ale mám rád i C/C++ a prekvapivo Scalu.

Jestli ono to nebude tim, ze delas ocividne frontend. Ostatne, to uz se psalo nekde tusim v Unix Bible, kde se popisovalo na prikladu Applistu a Unixaku - kde Unixaci se staraji vic o to, jak ma fungovat mechanismus aplikace, kdezto Applisti vice o to, jak tu aplikaci bude chtit pouzivat jeji uzivatel. Coz vytvori 2 ruzne pristupy k veci a ruzne vysledky.

Ja jsem backend programator - me vice zajima poradnost mechanismu nez to, jak to bude pouzivat uzivatel. Kdybych delal frontend, asi me bude mene zajimat mechanismus a vice zpusob pouzivani uzivatelem. Budu psat aplikaci ze strany UI a co je v pozadi bude podrizeno UI.

Bylo by dobre, kdyby si to programatori uz konecne uvedomili a prestali na sebe navzajem kydat hnuj.

[Cikáda]

Python je na tom podle mne mnohem lépe, určitě ho vyzkoušej.

Předpokládám, že řeč je o typech a dynamickém jazyku. Mohl bys to trochu rozvést?

[Mlocik97]

E: p.s. moja najbolúbenejšia kombinácia technológií je Node.js+Angular+Golang+Redis všetko cestou MVC ... ale mám rád i C/C++ a prekvapivo Scalu.

Jestli ono to nebude tim, ze delas ocividne frontend. Ostatne, to uz se psalo nekde tusim v Unix Bible, kde se popisovalo na prikladu Applistu a Unixaku - kde Unixaci se staraji vic o to, jak ma fungovat mechanismus aplikace, kdezto Applisti vice o to, jak tu aplikaci bude chtit pouzivat jeji uzivatel. Coz vytvori 2 ruzne pristupy k veci a ruzne vysledky.

Ja jsem backend programator - me vice zajima poradnost mechanismu nez to, jak to bude pouzivat uzivatel. Kdybych delal frontend, asi me bude mene zajimat mechanismus a vice zpusob pouzivani uzivatelem. Budu psat aplikaci ze strany UI a co je v pozadi bude podrizeno UI.

Bylo by dobre, kdyby si to programatori uz konecne uvedomili a prestali na sebe navzajem kydat hnuj.

hmm, ja sa osobne považujem za full-stack programátora.... inak netuším podľa čoho si usúdil že riešim front-end.

[Zabanovaný Anonymní Troll]

E: p.s. moja najbolúbenejšia kombinácia technológií je Node.js+Angular+Golang+Redis všetko cestou MVC ... ale mám rád i C/C++ a prekvapivo Scalu.

Jestli ono to nebude tim, ze delas ocividne frontend. Ostatne, to uz se psalo nekde tusim v Unix Bible, kde se popisovalo na prikladu Applistu a Unixaku - kde Unixaci se staraji vic o to, jak ma fungovat mechanismus aplikace, kdezto Applisti vice o to, jak tu aplikaci bude chtit pouzivat jeji uzivatel. Coz vytvori 2 ruzne pristupy k veci a ruzne vysledky.

Ja jsem backend programator - me vice zajima poradnost mechanismu nez to, jak to bude pouzivat uzivatel. Kdybych delal frontend, asi me bude mene zajimat mechanismus a vice zpusob pouzivani uzivatelem. Budu psat aplikaci ze strany UI a co je v pozadi bude podrizeno UI.

Bylo by dobre, kdyby si to programatori uz konecne uvedomili a prestali na sebe navzajem kydat hnuj.

hmm, ja sa osobne považujem za full-stack programátora.... inak netuším podľa čoho si usúdil že riešim front-end.

Delal jsi nekdy v enterprise, napr. v bance? Kde business logika nejakeho typu objednavky je tak komplexni, ze jeji zpracovani trva nekolik dni nebo i tydnu, a vyzadje mit specializovanou komponentu ktera predstavuje stavovy stroj, protoze jinak by se v tom ani prase nevyznalo a bylo by to nereliablni? Kde centralni databaze ma 200 tabulek a kazda muze mit az 100 sloupcu? jestli ne, tak jsi u me frontendar 

Mimochodem, vis jak vznikne databaze, co ma 200 tabulek se 100 sploupci? Vznikne postupne, bez planovani, tak jak byly jednotlive veci potreba postupne rostla - tzn. takovy shit ve kterem se neda dobre vyznat vznikne praveze metodologii, ktera se uplatnuje v javascriptu.



Obecne se da rict, ze dobra poskladanost aplikace vyzaduje cas a peci. A kdyz se do toho ten cas neinvestuje, tak proste vznikne shit. Neexistuje nejaka vsespasna metodologie nebo jazyk, ktera udela pekny design za programatora. OOP je neco, co umoznuje do programoveho kodu vlozit novy prvek/uroven poradku. Stejne tak staticke typovani. Ale oboje je samo o sobe jen prostredek - jestli tomu ten programator cas venuje, aby to ten prostredek vyuzil k dobremu designu a lepsi prehlednosti kodu, to je vec druha. Mozna i za pomoci dynamickeho jazyka se da dosahnout podobne miry poradku - ale neverim tomu, ze to bude jednoddussi a spise si myslim, ze to bude tezsi.

[Reklama]

[Kit]

Co je spatneho na tom, mit design udelany tak, ze budu rozlisovat kategorie funkci na api, vstupni mappery, vystupni mapper, service, domenu, dao a background joby? Kazde kategorii bude i odpovidat jedna slozka. To mi vysvetli, co je na tom tak spatneho. - to ti prijde prebyrokratizovane?

Jaká jedna odpovídající složka? Copak ty složky pojmenováváš názvem kategorie? Správně mají být pojmenovány názvem domény, o kterou se starají. Zbytečně ti vzniká další vrstva adresářů. Struktura má být plochá, dvouvrstvá, maximálně třívrstvá. V žádném případě se z toho nesmí dělat taxonomie. Slova mapper, service, domain apod. do těch názvů nepatří - jinak z návrhu vznikne paskvil.

Videl jsem 2 zpusoby v praxi - slozky pojmenovane nazvem domeny o kterou se staraji a slozky s nazvem kategorie. Ta prvni varianta se vyskytovala v enviromentu kde se moc nedelalo OOP, architektura byla plocha. Ta druha varianta se pouzivala v enviromentu, kde se delalo OOP.

u me zatim vede v prehlednosti 2 varianta - slozky nesou nazev kategorie. Ale nic samozrejme neni tak jednoduche, aby to bylo cernobile - nekdy je vliv domeny (nebo spise subdomeny - nejakou domenu resi komponenta) natolik znacny, ze z hlediska prehlednosti je vhodne, aby mela svou vlastni slozku. (napr. authentikace)

Vzhledem k tomu ze komponenty by nemely byt monoliticke hydry, ale mely byt specializovane na neco, dava o to vice rozdeleni slozek dle kategorii smysl, protoze vsechny tridy jaksi resi vicemene jednu a tutez domenu, ktera je definovana prave tou komponentou samotnou.

Muzu mit slozku domain a v ni mit domenove objekty, protoze uz ten samotny domenovy model hodne napovida o tom, co vlastne ta komponenta bude delat, jake problematiky uloh resi.

V žádném případě nejsem příznivcem monolitů a proto se mi nelíbí, jak se toho zhostil autor zmíněného blogu. V každé třídě hezky 2-4 atributy a 3-7 metod. Víc není třeba. Skupinu tříd, která se stará o jednu doménu, dám do jednoho adresáře. Domény, které jsou logicky nad ní nebo pod ní, jsou v jiném adresáři na stejné úrovni. Můžeš to srovnat s hexagonální architekturou, která nevytváří zbytečnou hierarchii.

Specializaci tedy nedělám podle kategorie, ale podle domény. Pokladna, sklad, ceník, košík. V každé doméně je kompletní MVC, třídy hezky vedle sebe. Když vytvářím další doménu, například slevy, tak nemusím běhat po celém vývojářském stromu, ale mám celé MVC pohromadě v jednom adresáři. Pokud by mi měla vzniknout duplicita kódu s jinou doménou, tak tu část kódu refaktoruji do nové domény a ta si pak žije svým životem.

Adresář s názvem "domain" u mne postrádá smysl, neboť bych v něm měl všechno.

[Kit]

Python je na tom podle mne mnohem lépe, určitě ho vyzkoušej.

Předpokládám, že řeč je o typech a dynamickém jazyku. Mohl bys to trochu rozvést?

Ohledně typovosti je mezi nimi významný rozdíl. NodeJS je slabě typovaný, ale Python je silně typovaný, což významně snižuje množství WTF při vývoji.

Měl jsem však na mysli ekosystém, který je dle mého názoru v Pythonu lepší.

[Mlocik97]

hmm, ja sa osobne považujem za full-stack programátora.... inak netuším podľa čoho si usúdil že riešim front-end.

Delal jsi nekdy v enterprise, napr. v bance? Kde business logika nejakeho typu objednavky je tak komplexni, ze jeji zpracovani trva nekolik dni nebo i tydnu, a vyzadje mit specializovanou komponentu ktera predstavuje stavovy stroj, protoze jinak by se v tom ani prase nevyznalo a bylo by to nereliablni? Kde centralni databaze ma 200 tabulek a kazda muze mit az 100 sloupcu? jestli ne, tak jsi u me frontendar 

Mimochodem, vis jak vznikne databaze, co ma 200 tabulek se 100 sploupci? Vznikne postupne, bez planovani, tak jak byly jednotlive veci potreba postupne rostla - tzn. takovy shit ve kterem se neda dobre vyznat vznikne praveze metodologii, ktera se uplatnuje v javascriptu.

v bance som nerobil, ale pracoval som na enterprise stredne komplexných aplikácií ako napr. casual hry, či webové aplikácie, ktoré spracuvávali špecifické dáta (stredne zložitou logikou).
v redisu neviem čo znamená pojem stĺpec, síce som robil aj s PostgreSQL, tam sa asi môžme baviť o stĺpcoch. A  áno je pravda že v prípade PostgreSQL som mal maximum 47 (+2) stĺpcov tabuľke v databáze, v ktorej dokopy bolo 28(+1) tabuliek alebo iný projekt síce len 14 stĺpcov ale 41 tabuliek (hodnoty v zátvorkách reprezentujú počet absolútne zbytočných "bazmekov" teda tabuliek či stĺpcov, ktoré neboli ani zmysluplné). Není to síce až 200, ale keďže som PostgreSQL použil len v 2 projektoch, a inak bežne používam noSQL, najmä ten redis, tak to sa moc porovnávať nedá. U mojich projektoch myslím že nemám až takú nutnosť použiť SQL relačné databázy. I tak si ale myslím že niečo o back-ende viem. Ale tak to je už každého subjektívny názor.

[Zabanovaný Anonymní Troll]

Co je spatneho na tom, mit design udelany tak, ze budu rozlisovat kategorie funkci na api, vstupni mappery, vystupni mapper, service, domenu, dao a background joby? Kazde kategorii bude i odpovidat jedna slozka. To mi vysvetli, co je na tom tak spatneho. - to ti prijde prebyrokratizovane?

Jaká jedna odpovídající složka? Copak ty složky pojmenováváš názvem kategorie? Správně mají být pojmenovány názvem domény, o kterou se starají. Zbytečně ti vzniká další vrstva adresářů. Struktura má být plochá, dvouvrstvá, maximálně třívrstvá. V žádném případě se z toho nesmí dělat taxonomie. Slova mapper, service, domain apod. do těch názvů nepatří - jinak z návrhu vznikne paskvil.

Videl jsem 2 zpusoby v praxi - slozky pojmenovane nazvem domeny o kterou se staraji a slozky s nazvem kategorie. Ta prvni varianta se vyskytovala v enviromentu kde se moc nedelalo OOP, architektura byla plocha. Ta druha varianta se pouzivala v enviromentu, kde se delalo OOP.

u me zatim vede v prehlednosti 2 varianta - slozky nesou nazev kategorie. Ale nic samozrejme neni tak jednoduche, aby to bylo cernobile - nekdy je vliv domeny (nebo spise subdomeny - nejakou domenu resi komponenta) natolik znacny, ze z hlediska prehlednosti je vhodne, aby mela svou vlastni slozku. (napr. authentikace)

Vzhledem k tomu ze komponenty by nemely byt monoliticke hydry, ale mely byt specializovane na neco, dava o to vice rozdeleni slozek dle kategorii smysl, protoze vsechny tridy jaksi resi vicemene jednu a tutez domenu, ktera je definovana prave tou komponentou samotnou.

Muzu mit slozku domain a v ni mit domenove objekty, protoze uz ten samotny domenovy model hodne napovida o tom, co vlastne ta komponenta bude delat, jake problematiky uloh resi.

V žádném případě nejsem příznivcem monolitů a proto se mi nelíbí, jak se toho zhostil autor zmíněného blogu. V každé třídě hezky 2-4 atributy a 3-7 metod. Víc není třeba. Skupinu tříd, která se stará o jednu doménu, dám do jednoho adresáře. Domény, které jsou logicky nad ní nebo pod ní, jsou v jiném adresáři na stejné úrovni. Můžeš to srovnat s hexagonální architekturou, která nevytváří zbytečnou hierarchii.

Specializaci tedy nedělám podle kategorie, ale podle domény. Pokladna, sklad, ceník, košík. V každé doméně je kompletní MVC, třídy hezky vedle sebe. Když vytvářím další doménu, například slevy, tak nemusím běhat po celém vývojářském stromu, ale mám celé MVC pohromadě v jednom adresáři. Pokud by mi měla vzniknout duplicita kódu s jinou doménou, tak tu část kódu refaktoruji do nové domény a ta si pak žije svým životem.

Adresář s názvem "domain" u mne postrádá smysl, neboť bych v něm měl všechno.

Tak tam mas ten design ocividne ovlivnen tim, ze to neni ciste backend a mas tam to MVC. To to UI ti prihodne definovalo rozdeleni balicku tak, jak to mas ted.

Kdyby to byl ciste backend a fontend by byl uplne oddeleny, treba v Reactu, tak bys mohl mit na backendu tohle:

domena
 Objednavka
 Uzivatel
 Produkt
 Dodani
 Platba

Na projektu jsem jeste MVC nikdy nemel a vzhledem k tomu, ze uz MVC moc nepouziva, se k tomu mozna uz ani nedostanu.

[Kit]

V žádném případě nejsem příznivcem monolitů a proto se mi nelíbí, jak se toho zhostil autor zmíněného blogu. V každé třídě hezky 2-4 atributy a 3-7 metod. Víc není třeba. Skupinu tříd, která se stará o jednu doménu, dám do jednoho adresáře. Domény, které jsou logicky nad ní nebo pod ní, jsou v jiném adresáři na stejné úrovni. Můžeš to srovnat s hexagonální architekturou, která nevytváří zbytečnou hierarchii.

Specializaci tedy nedělám podle kategorie, ale podle domény. Pokladna, sklad, ceník, košík. V každé doméně je kompletní MVC, třídy hezky vedle sebe. Když vytvářím další doménu, například slevy, tak nemusím běhat po celém vývojářském stromu, ale mám celé MVC pohromadě v jednom adresáři. Pokud by mi měla vzniknout duplicita kódu s jinou doménou, tak tu část kódu refaktoruji do nové domény a ta si pak žije svým životem.

Adresář s názvem "domain" u mne postrádá smysl, neboť bych v něm měl všechno.

Tak tam mas ten design ocividne ovlivnen tim, ze to neni ciste backend a mas tam to MVC. To to UI ti prihodne definovalo rozdeleni balicku tak, jak to mas ted.

Na projektu jsem jeste MVC nikdy nemel a vzhledem k tomu, ze uz MVC moc nepouziva, se k tomu mozna uz ani nedostanu.

REST API mám routerem nasměrováno přímo na ty domény. V nich však už frontend neřeším - ten je v dalších doménách, které dělají HTML, XML, JSON nebo třeba PDF podle typu požadavku. V hierarchii jsou na stejné úrovni.

src
 Objednavka
 Uzivatel
 Produkt
 Dodani
 Platba
 Login
 Databáze
 Admin
 Dom
 Html
 Xml
 Pdf
... atd

[qelurg]

Mimochodem, vis jak vznikne databaze, co ma 200 tabulek se 100 sploupci? Vznikne postupne, bez planovani, tak jak byly jednotlive veci potreba postupne rostla - tzn. takovy shit ve kterem se neda dobre vyznat vznikne praveze metodologii, ktera se uplatnuje v javascriptu.

Vznikne tak, ze se o datovy model stara nekompetentni prase. Neni to nastrojem, ale clovekem.

[qelurg]

Delam v Jave a pokousim se o javascript.

Dam priklad. Na zacatku vseho bych si rad udelal domenovy model, protoze jsem tak zvykly - nekde prece sakra musim mit definovane s jakymi daty vlastne budu pracovat, to by v tom byl jinak binec.

No takze si udelam slozku domain a tam si davam 1 file per class. Jenze jsem se zrovna zasekl u te veci, ze si potrebuju specifikovat fieldy mych domenovych trid a nemuzu tak specifikovat daotvy typ. Co s tim jako mam delat kdyz tam nemuzu mit ani datovy typ? Tak napr. budu tam chtit mit typ predstavujici datetime s casovou zonou. Co s tim, kdyz to tam nemuzu specifikovat? Jak bude potom nejaky kolega programator, nebo ja za par mesicu, vedet, co ty jednotlive atributy trid vlastne predstavuji?

Tak si udelej domenovy model, nechapu, co ti v tom brani.

Kolega programator se podiva do dokumentace k programu a bude mit jasno.

[Wavelet]

Delam v Jave a pokousim se o javascript.

Dam priklad. Na zacatku vseho bych si rad udelal domenovy model, protoze jsem tak zvykly - nekde prece sakra musim mit definovane s jakymi daty vlastne budu pracovat, to by v tom byl jinak binec.

No takze si udelam slozku domain a tam si davam 1 file per class. Jenze jsem se zrovna zasekl u te veci, ze si potrebuju specifikovat fieldy mych domenovych trid a nemuzu tak specifikovat daotvy typ. Co s tim jako mam delat kdyz tam nemuzu mit ani datovy typ? Tak napr. budu tam chtit mit typ predstavujici datetime s casovou zonou. Co s tim, kdyz to tam nemuzu specifikovat? Jak bude potom nejaky kolega programator, nebo ja za par mesicu, vedet, co ty jednotlive atributy trid vlastne predstavuji?

Tak si udelej domenovy model, nechapu, co ti v tom brani.

Kolega programator se podiva do dokumentace k programu a bude mit jasno.

Vůbec nechápu co mu brání při modelování domény. Jasně implementace je potom snazší v nějakém rozumném jazyku, ale Java zrovna pro DDD taky není ideální, zvlášť když jeden potřebuje hromadu Value Objects = neustálý boj s equals a hashcode. Nic proti Javě, ale tady bude problém jinde než v Node.

[qelurg]

Vůbec nechápu co mu brání při modelování domény.

Tak to já zase chápu, nazývá se to stereotypní myšlení.

[Wal-De-Mar]

Páči sa mi táto debata