Vlákno názorů k článku
Nejvíce vývojářů má JavaScript, Python a Java, Rust roste nejrychleji od CTCCTCGGCGGGCACGTAG - Zajimave, ze ve sloupci "least popular in" se...

Chcete tvrdit, ze Ruby se pouziva prevazne mimo web?

> Chcete tvrdit, ze Ruby se pouziva prevazne mimo web?

Teď už evidentně ano :-D

Kromě Rails se Ruby používá hlavně v souvislosti s Metasploitem. Dobrá, i to je svým způsobem web ;)

Z Vasich minulych komentaru vim, ze delate v typescriptu. Delal jste nekdy s Djangem nebo Rails? Podle me hlavni feature tech frameworku je ORM, nad kterym jsou postavene, pro nodejs nic podobneho neznam, Delam v obojim, v nodejs typicky musite napsat mnohem vic kodu.

Navic Javascriptu chybi nektere syntakticke featury (pretezovani operatoru), aby bylo mozne vytvorit pekne ORM s DSL. Kvuli tomu nejde vytvorit ani naivne se tvarici bigint.

24. 5. 2022, 12:33 editováno autorem komentáře

*nativne

Pointa mého příspěvku je právě v tom, že se aplikace z modelu Django / Rails / Wicket / ... přesouvají na klienta, kde přistupují k datům přes REST / GraphQL API. (Samozřejmě taková (klientská) aplikace ORM ani DSL nepotřebuje.)

Mimochodem ORM, to je taková ta věc, na kterou se tady v diskusi vždycky snese smršť zhnusených komentářů jak je to celé odporně pomalé, neefektivní a vlastně zcela nepoužitelné? ;-)

Psal jsem nějaké věci s ORM v Javě / Kotlinu a pak sever v TS, no zas takový rozdíl to pro jednoduché věci není. Cool začíná být ORM až v okamžiku, kdy chcete traverzovat po vazbách mezi objekty a ono vám automaticky dohrává potřebná data. Ale tady jsme pak u toho výkonu. V bance, co jsem dělal, sice měli v BE ORM (Hibernate, myslím), ale dotazy stejně dělali přes nativní query, právě kvůli výkonu.

A k čemu takový nativně se tvářící BigInt je? Osobně mám rád, když je z kódu jasně vidět, co se tam vlastně děje a to s přetěžováním operátorů moc nejde dohromady. Proto ho spíš nemám rád, i když u čistě numerických věcí jako je BigInt ho ještě uznávám. Když ho v JS / TS nemám, tak prostě píšu výrazy s BigIntem pomocí funkcí (a.add(b)). Pokud celý BE není jen o tom, tak se to dá snést.

Tak pokud srovnavate s javou, nedivim se, ze vam typescript prijde expresivni.

Podle me nemate moc predstavu co tento typ frameworku resi (API, uzivatelsky model ...), a neresi (nic ani vzdalene podobneho wicketu).

24. 5. 2022, 23:39 editováno autorem komentáře

> Podle me nemate moc predstavu co tento typ frameworku resi (API, uzivatelsky model ...), a neresi (nic ani vzdalene podobneho wicketu).

A na to jste přišel jak? Wicket jsem zmiňoval kvůli tomu, že se zde bavíme o použití pro web. API s ORM / DSL to téhle kategorie nespadá (minimálně z hlediska toho reportu), i když ho třeba v důsledku webová aplikace používá.

Tak zrovna takový REST server se v Djangu programuje docela příjemně.

Nechápal jsem negativní postoj některých lidí k ORM do té doby, než jsem se setkal s ORM v PHP (Doctrine) a JS (TypeORM) a lehce zahlídl Javu (Hibernate). Musím říct, že to, co jsem, zvyklí na Django (a malinko SQLAlchemy) považoval za naprosto samozřejmé, v jiných ORM buď zcela chybí nebo je tak strašně přes ruku, že to opravdu moc nedává smysl.

Pro RESTové rozhraní nad DB u menšího až středně velkého projektu je pro Django jednoznačnou volbou. Jestli to autoři průzkumu považují za web vývoj nevím - pročetl jsem celý ten report a nijak to tam není vysvětleno.

To uplne chapem, ako clovek odchovany na Entity Framewoku a LINQ-u mi prisli tie PHP-ckoveske a RoR ORM ako ciste netypove zlo, kde bolo fakt lahsie si napisat plain SQL ako pain ORM.

V JS jsou lepsi ORM nez TypeORM, ktere je snad uz mrtve. Sequelize je pouzitelne, i kdyz ne moc moderni. Narozdil od TypeORM ho autori dotahli do pouzitelneho stavu.

Libi se mi Objection ORM, je postavene nad knex, coz je pouzitelny query builder.

Podle me rozsireni ORM-based frameworku v JS a zejmena TS brani lpeni na oddeleni DB entit a aplikacni logiky do oddelenych vrstev. Dogma, ktere pochazi asi z Java sveta.

Django a Rails tezi z navazanosti aplikacni logiky na DB modely, tzv fat-model pristup. V node byl tomuhle pristupu nejbliz asi mongoose a MERN stack. Sveho casu popularni.

Psal jsem nějaké věci s ORM v Javě / Kotlinu a pak sever v TS, no zas takový rozdíl to pro jednoduché věci není. Cool začíná být ORM až v okamžiku, kdy chcete traverzovat po vazbách mezi objekty a ono vám automaticky dohrává potřebná data. Ale tady jsme pak u toho výkonu. V bance, co jsem dělal, sice měli v BE ORM (Hibernate, myslím), ale dotazy stejně dělali přes nativní query, právě kvůli výkonu.
Problém je, že Hibernate málokdo rozumí a spousta lidí ani netuší, že je tam ještě nějaká cache. Tyhle lidi pak všude vysvětlují, jak je Hibernate špatný. Jasně s native query a využití všech funkcí databáze lze dosáhnout lepšího výkonu. Jenže to není hlavní cíl ORM, důležité je aby se s tím snadno dělalo a aby člověk pořád nemusel řešit, jak je to v té databázi provázané atp.

Hlavni ucel ORM je popis vztahu mezi entitami. Potom muzete psat veci jako

User.objects.filter(groups__permissions=p)

Coz vytvori join pres 4 tabulky, bez rucniho psani podminek joinu

Cache na urovni ORM jsem nikdy nepouzil.

Vetsinou chcete ziskat cely vysledek jedinym dotazem, jehoz vygenerovani muze ORM usnadnit, jinak nemuzete pouzit strankovani s generickym razenim.

25. 5. 2022, 12:41 editováno autorem komentáře

Prave GraphQL a REST API je v Djangu temer bezpracne. Vetsinou staci jen povolit, funguje out of box, vcetne vazeb. Potrebna logika je soucasti modelu.