node.js MySql ORM

[Wuu]

Kādus lietojam? Ieteicams ilgāk. Standartā, reāli tracina darboties ar MySql uz node.js un šobrīd nav iespējas pāriet uz ko jēdzīgāku.

 

Sequelize nav variants, tad es labāk veltu nedēļu un uzrakstu pats savu, neko lietoju kaut ko tik drausmīgu. 

 

 

[F3llony]

Bookshelf.js. Ja būvē kaut ko lielāku, iespējams ir jēga skatīties uz kaut ko līdzīgu loopback.io

[yuppio]

Intereses pēc - kas tev tieši nepatīk Sequelize? Pamazām atsakamies no MongoDB, līdz ar to nesen sākām izmantot Sequelize, pagaidām nekas nesāp.

[briedis]

Intereses pēc - kas tev tieši nepatīk Sequelize? Pamazām atsakamies no MongoDB, līdz ar to nesen sākām izmantot Sequelize, pagaidām nekas nesāp.

 

Offtopiks, bet interesanti - kāpēc no mongo atsakāties? :)

[yuppio]

Diez gan neprognozējami strādā replikācija, izmēģināti visādi setupi ar shardingiem u.c. variācijas par tēmu, bet stabilu rezultātu nevar no neviena dabūt ārā, kas strādātu adekvāti mūsu vajadzībām.

 

Vienkārši mums tā problēma ir tajā, ka dati jāsinhronizē starp n-tajiem kontinentiem, līdz ar to vajag viņus kkā db levelī replicēt, lai katrā reģionā būtu data sets ātri accessojams, kas ar mongo diez gan sāpēja ar laiku. Īsumā - mongodb ir sūds mūsu gadījumā :) Mysql replikācija daudz stabilāk uzvedas. LĪdz ar 5.7 mysql arī sāk paradīties JSON supports, tā kā back to basics.

[anon]

Mongo ir nestabils sūds, tak pilns internets pierakstīts. Ar mysql arī var dabūt scale, atliek tikai izmantot devnull kā storage. Un nevajag gaidīt mysql, postgres jau tagad ir normāls json, normāls scale un normāls sql.

Edited January 16, 2016 by anon

[Wuu]

Bookshelf.js. Ja būvē kaut ko lielāku, iespējams ir jēga skatīties uz kaut ko līdzīgu loopback.io

 

Loopback izskatījās ok, līdz gribēju piejūgt socket.io. Nepavilku. Ja vajag prastu REST api, tad gan baigā bomba un ērtība.

 

Sequelize, manuālis drausmīgs, loģikas nekādas, ļoti atgādina PHP :> Pēc Moongose, liekas ka viņi pīpē kaprona zeķes. Arī github'ā, tās lietas, ko atbild autori, liek domāt, ka production not ready 100%.

 

Ar MongoDB ir viena problēma, cilvēki sūdzas, jo lietot nemāk un nesaprot, kāpēc MongoDB neuzvedas kā MySql. Es ar sākuma biju skeptisks, bet katru reizi lasot viņu problēmas, smiekli nāk.

Visiem viņiem ceļš uz https://university.mongodb.com/

[yuppio]

Mazizmēra projektiem Mongo ir ļoti labs imho, ja nevajag baigi scale`ot lietas un/vai replicēt. Anyway štelle, ka by default`ā write concern`s ir tāds, ka "varbūt ierakstīja" ir diez gan savādi imho.

 

Mongoose arī bija visādas figņas un developeri īpaši atsaucīgi nebija uz ātru labošanu, bugs imho bija saistīts ar read preference flagiem (ja izmanto replikāciju), kur tika ignorēti padodamie flagi vai kkas tāds. Ar to gribu teikt, ka problēmas un bugi anyway ir visiem, jautājums cik ātri/lēni kkas tiek darīts lietas labā. Mongoose iebūvēto promisu supports arī ir kaka (mpromise implementācija sux).

 

Sequelize tādā ziņā arī bija salauzts pēdējās versijās ar repliku izmantošanu saistītas lietas, bet pēc īsas paraudāšanas, fixi tika izdarīti.

[F3llony]

Loopback izskatījās ok, līdz gribēju piejūgt socket.io. Nepavilku. Ja vajag prastu REST api, tad gan baigā bomba un ērtība.

 

Jo Loopback tam nav paradzēts. Socket.io ir reāl-laikā barot kaut kādus datus. Darbam ar dokumentiem un CRUDam socket.io nav vajadzīgs, un nav pat vēlams. Priekš kam tev atvērtus soketus turēt ja tev viens klients atsūta varbūt vienu updeitu reizi minūtē.

[spainis]

Mongo problēma var nmap engine'u bija/ir collection level locking(2.6 bija vēl db level locks)

[Wuu]

Jo Loopback tam nav paradzēts. Socket.io ir reāl-laikā barot kaut kādus datus. Darbam ar dokumentiem un CRUDam socket.io nav vajadzīgs, un nav pat vēlams. Priekš kam tev atvērtus soketus turēt ja tev viens klients atsūta varbūt vienu updeitu reizi minūtē.

 

Baigi ērti piejūgt pie Flux storēm un pušot atjauninājumus/notifikācijas, un ir daudz ērtāk strādāt, ja clients ir uz Javascripta uzrakstīt. Sūti pa taisno objektus, bez jebkādas konvertācijas JSON un atpakaļ uz objektiem.

Cik studēju, atvērts sockets neprasa ēst. Kad pamēģini pastrādāt ar socket.io, galīgi nav vēlmes iet atpakaļ uz akmens laikmetu. Protams milzīgām lapām, tas nav variants.

 

Sākuma ar biju skeptisks, bet tad uzrakstīju JavaScript interneta ātruma mērītāju, kas lieto socket.io. Pirmkārt rāda precīzus mērījumus, otrkārt līdz 120mb/s sūta, un nejūt. Neesmu mēģinājis ar diviem datoriem lokāli, iespējams varētu vairāk izspiest. 

[F3llony]

Baigi ērti piejūgt pie Flux storēm un pušot atjauninājumus/notifikācijas, un ir daudz ērtāk strādāt, ja clients ir uz Javascripta uzrakstīt. Sūti pa taisno objektus, bez jebkādas konvertācijas JSON un atpakaļ uz objektiem.

Cik studēju, atvērts sockets neprasa ēst. Kad pamēģini pastrādāt ar socket.io, galīgi nav vēlmes iet atpakaļ uz akmens laikmetu. Protams milzīgām lapām, tas nav variants.

 

Huh? Pirmā daļa - jā, tam tas arī ir paredzēts. Par konvertāciju - vari sīkāk, kas tev kur jākonvertē? Gan websocketi, gan HTTP ir tikai transports. Atšķirība tikai tajā, ka HTTP ir con=>message=>data=>dcon, bet websockets ir con=>message=>data=>message=>data=>(...)=>dcon. 

 

Atvērts sockets ir atvērts sockets un ēst prasa tik pat daudz kā jebkura cita atvērta konekcija. Un tava kaste nevar turēt infinite daudz atvērtu soketu. Pat ja tavs apmeklētājs neko nedarīs, bet turēs lapu atvērtu - tavs sockets vienalga karāsies atvērts. Ja tu jamo virini manuāli - zūd visa soketu jēga.

[codez]

Huh? Pirmā daļa - jā, tam tas arī ir paredzēts. Par konvertāciju - vari sīkāk, kas tev kur jākonvertē? Gan websocketi, gan HTTP ir tikai transports. Atšķirība tikai tajā, ka HTTP ir con=>message=>data=>dcon, bet websockets ir con=>message=>data=>message=>data=>(...)=>dcon.

 

Socketu plusi:

- socketiem nav jāgaida konekcijas izveidošana, kas pie bremzīga tīkla aiz n-tiem firewāliem aizņem reāli jūtamu laiku, tāpēc aizture ir mazāka.

- socketiem var sūtīt datus no servera, negaidot, kad klients tos paprasīs. Tas ir liels bonuss.

- sockets var sūtīt binārus datus, kas atkarībā no situācijas, ļauj samazināt datu plūsmu pat līdz 5 reizēm.

Tas, ko esmu pamanījis, ka arvien vairāk un vairāk parastas web appas, kuras varētu iztikt bez tā, izvēlas websocketus, jo ir daudz bonusu.

 

Atvērts sockets ir atvērts sockets un ēst prasa tik pat daudz kā jebkura cita atvērta konekcija. Un tava kaste nevar turēt infinite daudz atvērtu soketu. Pat ja tavs apmeklētājs neko nedarīs, bet turēs lapu atvērtu - tavs sockets vienalga karāsies atvērts. Ja tu jamo virini manuāli - zūd visa soketu jēga.

Viena kaste var mierīgi turēt 100k - 1M atvērtu konekciju (atkarībā no tehnoloģijas kādu izmanto). Tas ne tuvu nebūs bootlnecks web sistēmai.

[Wuu]

Huh? Pirmā daļa - jā, tam tas arī ir paredzēts. Par konvertāciju - vari sīkāk, kas tev kur jākonvertē? Gan websocketi, gan HTTP ir tikai transports. Atšķirība tikai tajā, ka HTTP ir con=>message=>data=>dcon, bet websockets ir con=>message=>data=>message=>data=>(...)=>dcon. 

 

Atvērts sockets ir atvērts sockets un ēst prasa tik pat daudz kā jebkura cita atvērta konekcija. Un tava kaste nevar turēt infinite daudz atvērtu soketu. Pat ja tavs apmeklētājs neko nedarīs, bet turēs lapu atvērtu - tavs sockets vienalga karāsies atvērts. Ja tu jamo virini manuāli - zūd visa soketu jēga.

 

 

Skaties,

 

Clienta pusē

 

Vārds, objekts, callback

io.emit('transfer', {func: '/user/logout', key: this.data.__session__key}, (data) => {
//Daram ar 'data' ko gribam
}) 

Server pusē, 

callback({ko vēlamies nosūtīt})

Un tas uzreiz izdarās klienta pusē, būtībā nosūtam funkciju. :)

 

Ērti! Tev nevajag clienta pusē taisīt klausītājus. Tāds vienkāršs get, vien sanāk.  Un var nosūtīt Javascript objektu/arraju kāds viņš ir, nevis JSON.stringify() un JSON.parse() turpu, šurpu.

Nezinu, varbūt ar HTTP tāpat var, neesmu redzējis, ka kād stā darītu, visur piedāvā jsonu konvertēt.

 

Būtībā, no mongo paņem arrayu un pa taisno viņu nosūti, kāds viņš ir.

Es kad atskatos, kā es šo daru ar PHP API un Ajax req... #%^&*#@(*#@*!!!#@

socket.on('transfer', (req, res) => {
    UserSchema.find({}, (err, docs) => {
        res(docs) //Pa taisno nosūtam uz clientu
    })
})

Edited January 19, 2016 by Wuu

[F3llony]

 Socketu plusi:

- socketiem nav jāgaida konekcijas izveidošana, kas pie bremzīga tīkla aiz n-tiem firewāliem aizņem reāli jūtamu laiku, tāpēc aizture ir mazāka.

- socketiem var sūtīt datus no servera, negaidot, kad klients tos paprasīs. Tas ir liels bonuss.

- sockets var sūtīt binārus datus, kas atkarībā no situācijas, ļauj samazināt datu plūsmu pat līdz 5 reizēm.

Tas, ko esmu pamanījis, ka arvien vairāk un vairāk parastas web appas, kuras varētu iztikt bez tā, izvēlas websocketus, jo ir daudz bonusu.

 

Viena kaste var mierīgi turēt 100k - 1M atvērtu konekciju (atkarībā no tehnoloģijas kādu izmanto). Tas ne tuvu nebūs bootlnecks web sistēmai.

• daļēji patiesība (it depends). Un pat ja būtu pilna, tas būs pamanāms vienīgi tad, ja būs pieklājīgs rec/s. Vienam updeitam x300 gados ieguvums būs nekāds...
• obviously. Tas jau tika minēts.
• ??? un HTTP nevar?! Tas ir kā, visas manas kaķu bildes značit transportē Somālijas imigranti?!

Tas ko tu esi pamanījis ir kaut kāda figņa, kārtējo reizi. Jo te būs websoketu mīnusi:

• ping/pong vēl jorpojām nav stabilas nekādas standarta implementācijas
• dcon events nav uzticams - ja klients vienkārši "aiziet prom", neemitējot dcon, tu par to uzzināsi tad, kad iztecēs taimauts - ja tas netiek pareizi apstrādāts, tevis sūtīto ziņu klients probably nesaņems. Ever.
• socket.io automātiski diskonektē/rekonektē pie taimautiem un idlē. Socketiem IR jāgaida konekcijas izveidošana, dotajā gadījumā pie zema rec/s socket.io nav nekāda ieguvuma pret xhr, izņemot iespēju sūtīt info no serverside, kas ne vienmēr vispār ir vajadzīgs.
• Websocketiem nav natīva ACK. Socket.io ir kaut kas līdzīgs ACK, bet vienalga diezgan rupjā veidā un pašam jāatseko vai ziņa tiešām līdz klientam/serverim ir nonākusi. CRC ftw, yayy! :D
• Paralēli xhr pieprasījumi? 2-6 tredi uz katru mērķa domēnu, atkarībā no pārlūka. Paralēli websocket pieprasījumi? 1 uz katru socketu. Un pamēgini iestumt websoketā tādu palielāku message, redzēsi kas notiks ar visām tām, kuras sekos... 

Viena kaste var turēt 100k-1M atvērtu konekciju, for sure. Tā pat, kā Nginx pilnīgi noteikti var nodrošināt 1M rec/s, ja viss, ko mēs sūtam šurpu turpu ir "Hello world"...

 

Visi kaut kā ierauga, oooo, cik skaists websocketu api/socket.io etc. bet pamanās piemirst, ka websocketi nav nekas daudz vairāk kā nedaudz smukāk iepakots TCP sockets. Ar visiem tiem pašiem plusiem. Un visiem tiem pašiem mīnusiem (+ some).

[F3llony]

 

Skaties,

 

Clienta pusē

 

Vārds, objekts, callback

io.emit('transfer', {func: '/user/logout', key: this.data.__session__key}, (data) => {
//Daram ar 'data' ko gribam
}) 

Server pusē, 

callback({ko vēlamies nosūtīt})

Un tas uzreiz izdarās klienta pusē, būtībā nosūtam funkciju. :)

 

Ērti! Tev nevajag clienta pusē taisīt klausītājus. Tāds vienkāršs get, vien sanāk.  Un var nosūtīt Javascript objektu/arraju kāds viņš ir, nevis JSON.stringify() un JSON.parse() turpu, šurpu.

Nezinu, varbūt ar HTTP tāpat var, neesmu redzējis, ka kād stā darītu, visur piedāvā jsonu konvertēt.

 

Būtībā, no mongo paņem arrayu un pa taisno viņu nosūti, kāds viņš ir.

Es kad atskatos, kā es šo daru ar PHP API un Ajax req... #%^&*#@(*#@*!!!#@

socket.on('transfer', (req, res) => {
    UserSchema.find({}, (err, docs) => {
        res(docs) //Pa taisno nosūtam uz clientu
    })
})

 

Ā, un tu domā kā socket.io to JSON array nosūta klientam kaut kādā citā, maģiskākā veidā? :D JSON.stringify un JSON.parse, tikai paslēpts no tevis, tādā pašā veidā kā jebkurai normālai HTTP bibliotēkai... Un nekādu funkciju tu nekur nesūti...

 

Tam pašam pretīgajam jQuery $.get('/wat/', (data) => { console.log(typeof data); }) ja serveris atgriezīs application/json no /wat/, data variablis arī būs JSON objekts jau.

 

Socket.io nav nekāda maģija. Klientiem, kas neatbalsta websocketus, socket.io vienalga fonā izmanto tos pašus XHR pieprasījumus...