Wuu Posted January 15, 2016 Report Share Posted January 15, 2016 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. Quote Link to comment Share on other sites More sharing options...
0 Wuu Posted January 19, 2016 Author Report Share Posted January 19, 2016 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. Quote Link to comment Share on other sites More sharing options...
0 codez Posted January 19, 2016 Report Share Posted January 19, 2016 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. Quote Link to comment Share on other sites More sharing options...
0 F3llony Posted January 19, 2016 Report Share Posted January 19, 2016 (edited) 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 January 19, 2016 by F3llony Quote Link to comment Share on other sites More sharing options...
0 codez Posted January 19, 2016 Report Share Posted January 19, 2016 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. Quote Link to comment Share on other sites More sharing options...
0 spainis Posted January 19, 2016 Report Share Posted January 19, 2016 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 Quote Link to comment Share on other sites More sharing options...
0 F3llony Posted January 19, 2016 Report Share Posted January 19, 2016 (edited) 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: signāls WS serverim (graceful shutdown) 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) 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 January 19, 2016 by F3llony Quote Link to comment Share on other sites More sharing options...
Question
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.
Link to comment
Share on other sites
21 answers to this question
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.