Jump to content
php.lv forumi
  • 0

node.js MySql ORM


Wuu

Question

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. 

 

 

Link to comment
Share on other sites

Recommended Posts

  • 0

Protams, bet to visu manā vietā dara socket.io. Man pusē, atkrīt, tam visam sekot līdzi :D

Man pēc Http Requestiem, socket.io atgādina maģiju. Atpakaļ mani nekas neiestums. Tas pats ar React, ja kaut kas ir lielisks, gribas nošauties, ja jālieto kas cits. 

Link to comment
Share on other sites

  • 0

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).

Tieši tā - nedaudz smukāks un kā jau iepriekš minēja nav jau visi tie paši plusi un mīnusi, tieši tās atšķirības viņu padara savādāku un daudzos gadījumos noderīgāku.

Link to comment
Share on other sites

  • 0

Protams, bet to visu manā vietā dara socket.io. Man pusē, atkrīt, tam visam sekot līdzi :D

Man pēc Http Requestiem, socket.io atgādina maģiju. Atpakaļ mani nekas neiestums. Tas pats ar React, ja kaut kas ir lielisks, gribas nošauties, ja jālieto kas cits.

Nu nu, maģija - viss, ko tavā vietā izdara socket.io šajā kontekstā ir izsauc JSON.stringify un JSON.parse otrā galā. Viss. Izlasi manu pēdējo postu iepriekšējā lapā... Nemaz vairs neliksies tik maģiski. It īpaši ja tādam loopback piekabina klienta pusē piemēram, vai nu angular-sdk vai kaut kādu restful.js

 

Tieši tā - nedaudz smukāks un kā jau iepriekš minēja nav jau visi tie paši plusi un mīnusi, tieši tās atšķirības viņu padara savādāku un daudzos gadījumos noderīgāku.

Nekādu īpašu atšķirība no programmētāja viedokļa starp parastu TCP socketu un websocket nav. Kā tas tehniski strādā "zem motora pārsega" Wuu gan jau maz interesē. Un arī tur, kas tad tik ļoti atšķiras? Handsheiks? Okei. Katrai envelopei ir izmērs un piederība. Nu labi, nevajadzēs skaitīt saņemtos un nosūtītos baitus. Vairāk nekas tur arī nav... Fundamentālas problēmas, kā bija ar TCP tā ir ar websocketiem. Par ko arī ir runa. Tāpēc arī mums ir viss HTTP - tieši lai izvairītos no šīm fundamentālajām problēmām.

Edited by F3llony
Link to comment
Share on other sites

  • 0

Piemēram, mans projekts biome3d nekādi nestrādātu ar http, pat ar visiem longpolliem, utml., jo ir nepieciešams saņemt informāciju no servera 20x sekundē.

Es protams saprotu, ka tā nav ikdienišķa web aplikācija, bet arvien vairāk web aplikācijas sastopas ar nepieciešamību pēc realtime datiem no servera.

Tas var būt kāds RT analītikas grafiks, čats, notificationi no servera, utml. Pirms websocketa visi lietoja longpoolus un daudz kur vēl lieto, bet tiem ir vajadzīgs regulārs reconects un liels headeru trafika overheads, ja saņemtie dati ir niecīgi. Ja nemaldos websocketa messidžam ir 6 baitu overheads, pretstatā kādiem 500 - 2000 baitiem http requesta gadījumā.

Un, ja jau nepieciešamība pēc websocketiem rodas, tad kāpēc arī visus pārējos datus netransportēt caur websocketiem.

Link to comment
Share on other sites

  • 0

viens liels websocket'u mīnus, ja ir nepieciešams restartēt aplikāciju serveri un tad visi tie miljoni ar konekcijām atkal gāžas iekšā, jo visi diskonektējās +- vienā laikā

 

un socket.io vienīgā "maģija" ir callback id sūtīšana un pieglabāšana @ client, server'is response'ā nosūtīs to pašu callback id un viss

Link to comment
Share on other sites

  • 0

Piemēram, mans projekts biome3d nekādi nestrādātu ar http, pat ar visiem longpolliem, utml., jo ir nepieciešams saņemt informāciju no servera 20x sekundē.

Es protams saprotu, ka tā nav ikdienišķa web aplikācija, bet arvien vairāk web aplikācijas sastopas ar nepieciešamību pēc realtime datiem no servera.

Tas var būt kāds RT analītikas grafiks, čats, notificationi no servera, utml. Pirms websocketa visi lietoja longpoolus un daudz kur vēl lieto, bet tiem ir vajadzīgs regulārs reconects un liels headeru trafika overheads, ja saņemtie dati ir niecīgi. Ja nemaldos websocketa messidžam ir 6 baitu overheads, pretstatā kādiem 500 - 2000 baitiem http requesta gadījumā.

Un, ja jau nepieciešamība pēc websocketiem rodas, tad kāpēc arī visus pārējos datus netransportēt caur websocketiem.

Tavs biome ir lielisks piemērs kur socketus var un pat ļoti vajag lietot - es domāju, ka flash transports jau sen visiem web spēļu deviem bija spēcīgi apnicis. Taču te ir nianse - websocketiem ir overhead kuru reti kāds ieskaita kopējā "maisā", un tas ir pareiza manis minēto edge keisu apstrāde. Tev biomē viens-divi zaudēti freimi no socketa nu noteikti neko nemainīs - nu labi, kādam čalim noraustīsies "blobs", fine, deal with it. Bet iedomājies šādu situāciju:

server>you have 300€
client>transaction(100€)
server>ack, you have 200€
client>transaction(100€)
(??? network nok (bebrs nolaidās uz wifi antenas))
server>ack, you have 100€
(??? network ok)
client>??? Server plz
client>retry transaction(100€)
server>lol ok you have 0€
client>wtfomgbbq

Līdz stulbumam ģeneralizēts un balstīts uz manu sarkastisko skatu uz dzīvi, bet tagad iedomājies, ja kāds tūnis kaut kādā naidžērijas bankā kaut ko šādu arī uztaisīs kaut kādā kritiskākā sistēmā, nereģistrēs klienta pusē vai pieprasījums ir ack, nepārbaudīs vai dotais pieprasījums nav ack arī pēc tam kad ir kļūda (nav ack), izdarīs kaut kādus pieņēmumus par steitu utt utjp. Šāda problēma var rasties un rodas, jo šeit ne tikai pats pieprasījums, bet arī servera atbilde nav sinhrona. Tradicionāli ir HTTP GET /send/money/100€ un rezultāts ir vai nu 200OK, vai nu 5xx ej mājās (content length mismatch, partial data, utt utjp), vai pūlo statusu kamēr ir OK (jo tas ir obvious thing, kas ir jādara, pat Dilbertam) - savukārt ar websocketiem tas varētu būt ne tik loģiski, it ipaši ja Dilberts testē localhostā, neizmanto toxiproxy/comcast utml tūļus, un vispār ģeneralizē kaut kādus pieņēmumus.

 

Un tas ir iemesls, kāpēc visus pārējos datus netransportēt - eksistē jau gadiem ilgi pārbaudīts transports, kurš ir sevi pierādījis kā līdz dumjumam stabils - HTTP. 

 

Es personīgi domāju, ka domāt HTTP vs WS ir galīgi greizi, tiem drīzāk vajadzētu vienam otru augmentēt, ne aizstāt - tevis minētajai biomei etc. un citiem līdzīgiem gadījumiem, no prob, ws ir super cool and fine. Bet citiem, savā ziņā "tranzakcionāliem" gadījumiem - pievienot komentāru, bloga postu, aizsūtīt Petjam vēstuli, es domāju HTTP ir pilnīgi okei. 

 

viens liels websocket'u mīnus, ja ir nepieciešams restartēt aplikāciju serveri un tad visi tie miljoni ar konekcijām atkal gāžas iekšā, jo visi diskonektējās +- vienā laikā

 

un socket.io vienīgā "maģija" ir callback id sūtīšana un pieglabāšana @ client, server'is response'ā nosūtīs to pašu callback id un viss

 

Totally piedzīvots keiss. Solution:

  1. signāls WS serverim (graceful shutdown)
  2. emit katram klientam (reconnect after: (plānotais offtime + laiks lai emitētu visiem ziņas + laiks nedaudz drošībai (teiksim 30 sekundes restartam) + (konekcijas N * "starpbrīdis")) sec)
  3. disconnect

Starprīdi rēķinājām mēs šādi (uz 1,000,000 konekcijām) i * 0.001, kā rezultāts bija:

reconnect after 30.001
reconnect after 30.002
reconnect after 30.003
reconnect after 30.004
reconnect after 30.005
reconnect after 30.006
reconnect after 30.007
reconnect after 30.008
reconnect after 30.009

kas pamatā ļāva atkopties ļoti, ļoti maigi. + vēl frontendā bija skripts, kas intervālus pagarināja gadījumā, ja konekcija neizdodas ar pirmo reizi (vairāk laika vajag lai atkoptos, utt).

 

Parasti plānotiem offtaimiem šis pats princips tika izmantots lai gracefully nokillotu serveri un tad load balancerim failover šos te pašus delayed konektus izmētātu pa pārējiem serveriem.

Edited by F3llony
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...