Node.js database polling

[ZeroXT]

Beste mensen,

Ik heb al een tijdje gegoogled maar ik kom er niet uit. Ik zou graag in combinatie met Node.js een MySQL database pollen op veranderingen.

Het uiteindelijke doel is een chat te maken en dit is de manier waarop ik het graag wil:

- Ajax request naar de server.
- Nodejs checkt continue of er al een nieuw bericht in de database geplaatst is.
- Zo ja, retourneren naar de client.

Ik weet dat hier ook Websockets voor gebruikt kunnen worden maar die worden niet in oudere browsers ondersteund.
Ik weet ook dat een Mysql database niet wordt aangeraden maar de database kan ik altijd nog veranderen.

Nu lukt een ajax request naar de server prima alleen ik weet niet hoe ik Nodejs kan gebruiken dat deze controleert of de database een nieuw bericht heeft ontvangen.

Zelf kwam ik uit op deze twee pagina's:

http://nodejsdb.org/2011/...ode-db-with-generic-pool/
http://stackoverflow.com/...-of-comet-for-longpolling

Kan iemand mij verder in de juiste richting schoppen?

[ThomasG]

Je kunt via je AJAX request parameters in de vorm van een POST of GET meegeven. Hier kun je bijvoorbeeld een timestamp van de laatste request meegeven, of desnoods het id van het laatst ontvangen bericht als je geen tijd bijhoud. En dit vervolgens meegeven aan de query, dus selecteer alle berichten uit de tabel die nieuwer zijn dan de timestamp.

Omdat het een chat applicatie wordt, zou ik het gaan cachen. De server vraagt in een X interval aan de database om nieuwe berichten, en slaat deze op in een cache. En laat je de gebruikers de cache pollen.

[ Voor 37% gewijzigd door ThomasG op 06-06-2013 17:00 ]

[HMS]

Zou je niet beter een soort message bus kunnen gebruiken waarmee je het ontvangende en versturende deel aan elkaar knoopt. Dus:

1. User X stuur bericht naar user Y
2. Server insert bericht van User X in database
3. Server plaats bericht in message bus dat bericht met Id Z voor User Y er is
4. NodeJS verwerkt bericht en pusht bericht naar user Y

Het server side pollen van een database lijkt mij namelijk niet echt een goede oplossing.

[Hydra]

ZeroXT schreef op donderdag 06 juni 2013 @ 16:40:
Ik weet dat hier ook Websockets voor gebruikt kunnen worden maar die worden niet in oudere browsers ondersteund.

http://socket.io/ heeft fallbacks naar o.a. flash voor browsers die websockets niet gebruiken. Werkt erg goed icm met Node.js IMHO.

Je kunt aan de Node.js kant een 'chatroom' object bijhouden die nieuwe berichten direct naar clients stuurt. Op die manier hoef je niet elke X seconden te checken of er nieuwe berichten zijn.

[Verwijderd]

Wat Hydra zegt. Socket.IO is wat je zoekt.

[TheNephilim]

Eensch met het bovenstaande. Als je polling gaat doen, loop je vroeg of laat wel tegen beperkingen aan. Zeker voor een chat, voelt het met polling al snel stroperig, terwijl push dan veel meer 'snappy' voelt.

Alternatieven voor Socket.IO/Node.js; http://www.ape-project.org/, http://pusher.com/, http://migratorydata.com/migratorydata-websocket-server.html

[Verwijderd]

TheNephilim schreef op vrijdag 07 juni 2013 @ 11:49:
Eensch met het bovenstaande. Als je polling gaat doen, loop je vroeg of laat wel tegen beperkingen aan. Zeker voor een chat, voelt het met polling al snel stroperig, terwijl push dan veel meer 'snappy' voelt.

Alternatieven voor Socket.IO/Node.js; http://www.ape-project.org/, http://pusher.com/, http://migratorydata.com/migratorydata-websocket-server.html

Hoewel je gelijk hebt dat polling wat 'stroperig' (grappige term trouwens) aan kan voelen geldt dit alleen voor short polling terwijl je, indien goed toegepast, met long polling toch wel een snappy resultaat kunt krijgen zonder teveel moeite of overhead.

[GlowMouse]

HMS schreef op donderdag 06 juni 2013 @ 16:58:
Zou je niet beter een soort message bus kunnen gebruiken waarmee je het ontvangende en versturende deel aan elkaar knoopt. Dus:

1. User X stuur bericht naar user Y
2. Server insert bericht van User X in database
3. Server plaats bericht in message bus dat bericht met Id Z voor User Y er is
4. NodeJS verwerkt bericht en pusht bericht naar user Y

Het server side pollen van een database lijkt mij namelijk niet echt een goede oplossing.

De database is de message bus, node.js moet hem alleen regelmatig pollen. Dat kan 10x per seconde, waarbij een resultaat vervolgens direct naar alle (long polling) clients gestuurd wordt.

[ZpAz]

GlowMouse schreef op vrijdag 07 juni 2013 @ 14:28:
[...]

De database is de message bus, node.js moet hem alleen regelmatig pollen. Dat kan 10x per seconde, waarbij een resultaat vervolgens direct naar alle (long polling) clients gestuurd wordt.

Pollen Nay, Pushen Yay. Als je 10 keer per seconde een query los laat op je database of er kijkt of er iets veranderd is en een uur lang verandert er niets. Dan heb je 36.000 nutteloze query's uitgevoerd en 36.000 keer bandbreedte verstookt.

Je moet gewoon op het moment dat er iets veranderd de database aanpassen en iedereen (die geintresseerd is in het betreffende bericht) een berichtje sturen, hee jongens, dit is upgedated!

[GlowMouse]

ZpAz schreef op vrijdag 07 juni 2013 @ 15:13:
[...]


Pollen Nay, Pushen Yay. Als je 10 keer per seconde een query los laat op je database of er kijkt of er iets veranderd is en een uur lang verandert er niets. Dan heb je 36.000 nutteloze query's uitgevoerd en 36.000 keer bandbreedte verstookt.

Je moet gewoon op het moment dat er iets veranderd de database aanpassen en iedereen (die geintresseerd is in het betreffende bericht) een berichtje sturen, hee jongens, dit is upgedated!

Technisch is het zeker mooier, maar je moet ook praktisch zijn. Die bandbreedte is vaak over een intern netwerk, het zijn zeer simpele queries waar de db-server nog voor geen procent mee wordt belast, en je voorkomt een extra dependency.

[Mint]

GlowMouse schreef op vrijdag 07 juni 2013 @ 15:17:
[...]

Technisch is het zeker mooier, maar je moet ook praktisch zijn. Die bandbreedte is vaak over een intern netwerk, het zijn zeer simpele queries waar de db-server nog voor geen procent mee wordt belast, en je voorkomt een extra dependency.

..waarbij je ook rekening moet houden met het feit dat dit geldt voor 1 user. Wat als dat er straks 500 zijn? Het feit dat je een extra dependency toevoegt weegt dan niet op tegen de besparingen op resources (zoals traffic) en eventuele winsten op het gebied van gebruikerservaring.

[GlowMouse]

adyta schreef op vrijdag 07 juni 2013 @ 15:21:
[...]


..waarbij je ook rekening moet houden met het feit dat dit geldt voor 1 user. Wat als dat er straks 500 zijn? Het feit dat je een extra dependency toevoegt weegt dan niet op tegen de besparingen op resources (zoals traffic) en eventuele winsten op het gebied van gebruikerservaring.

In node.js hoef je maar één timer te hebben die zorgt voor die 10 queries/sec. Die stuurt het resultaat naar alle clients.
De besparingen die je noemt zijn maar klein, terwijl downtime door niet functionerende software veel kostbaarder is. Daarnaast moet je investeren in kennis over de extra software.

[storeman]

Kun je geen trigger om je database zetten die vervolgens een command uitvoert om NodeJS te verwittigen dat er iets is veranderd. NodeJS communiceert dan met je clients.

Het gaat hier over longpolling en dergelijke, maar volgens mij is dat niet de vraag van de TS. Hij wil clients updaten op het moment van een table update.

Je kunt natuurlijk in de applicatie die de wijzigingen doet, ook een trigger inbouwen, maar als er meerdere applicaties zijn die naar de database schrijven, wordt dat een lastig verhaal.

@adyta: 500 users zijn geen probleem. NodeJS kan dit gewoon doen in een interval van bijv 100ms. Dit is onafhankelijk van de gebruikers.

@TS: Waarom beperk je je keuze tot NodeJS maar dan geen websockets gebruiken? Je zou ook een PHP script kunnen maken of iets anders. Je zou zelfs een bestand kunnen wijzigen welke gechecked wordt dmv ajax.

NodeJS kan dit juist goed oplossen met websockets en een eventuele fallback naar long-polling AJAX.

Het is een beetje rommelig verhaal, maar dat is de topicstart ook. Welk probleem heb je nu precies?

[ZpAz]

GlowMouse schreef op vrijdag 07 juni 2013 @ 15:24:
[...]

In node.js hoef je maar één timer te hebben die zorgt voor die 10 queries/sec. Die stuurt het resultaat naar alle clients.
De besparingen die je noemt zijn maar klein, terwijl downtime door niet functionerende software veel kostbaarder is. Daarnaast moet je investeren in kennis over de extra software.

Een mindere fancy push manier zou kunnen zijn om "tussen" de insert / update / delete query's te gaan zitten waar die aangeroepen worden. Vanuit daar enkel zeggen naar je clients "er is iets upgedated". En dan je "polling" éénmalig uit te voeren.

[Vinze]

Ik zou zeggen:
- Node.js (server)
- Express.js (framework)
- Socket.io (websockets, zelfs voor oude browsers)
- Mongoose (ORM module voor MySql)

Dan werkt het in 95% van de browsers, is het zowel cliënt als server side supersnel en betrouwbaar. En het zal ook meteen toekomst bestendig zijn doordat je niet afhankelijk bent van oude technieken. Mocht jij of iemand anders later functionaliteiten toe willen voegen, wordt je in ieder geval niet beperkt door de techniek.

[ZeroXT]

Hartelijk bedankt voor alle antwoorden maar jullie begrijpen mijn vraag verkeerd.

Ik vraag hoe ik met Node.js een MySQL database kan pollen zoals je in mijn topicstart kan lezen. Ik vraag dus niet hoe ik het op de client moet regelen en of ik wel of niet websockets moet gebruiken etc.

[danslo]

ZeroXT schreef op vrijdag 07 juni 2013 @ 19:09:
Hartelijk bedankt voor alle antwoorden maar jullie begrijpen mijn vraag verkeerd.

Ik vraag hoe ik met Node.js een MySQL database kan pollen zoals je in mijn topicstart kan lezen. Ik vraag dus niet hoe ik het op de client moet regelen en of ik wel of niet websockets moet gebruiken etc.

Waarom wil je pollen? Met socket.io krijg je een event callback wanneer er een bericht binnenkomt, die kan je meteen naar andere clients sturen.

Daarnaast kan je altijd nog MySQL er aan hangen om de berichten op te slaan maar constant pollen is echt niet meer van deze tijd

[ThomasG]

danslo schreef op vrijdag 07 juni 2013 @ 19:20:
[...]


Waarom wil je pollen? Met socket.io krijg je een event callback wanneer er een bericht binnenkomt, die kan je meteen naar andere clients sturen.

Daarnaast kan je altijd nog MySQL er aan hangen om de berichten op te slaan maar constant pollen is echt niet meer van deze tijd

Hij bedoelt waarschijnlijk pollen als in: hoe hij kan zien wanneer er nieuwe berichten zijn in de database, zodat hij deze kan pushen naar de clients.

[danslo]

ThomasG schreef op vrijdag 07 juni 2013 @ 19:42:
[...]
Hij bedoelt waarschijnlijk pollen als in: hoe hij kan zien wanneer er nieuwe berichten zijn in de database, zodat hij deze kan pushen naar de clients.

Ik weet wat hij met pollen bedoeld, het is alleen een achterhaald concept.

[ZpAz]

ZeroXT schreef op vrijdag 07 juni 2013 @ 19:09:
Hartelijk bedankt voor alle antwoorden maar jullie begrijpen mijn vraag verkeerd.

Ik vraag hoe ik met Node.js een MySQL database kan pollen zoals je in mijn topicstart kan lezen. Ik vraag dus niet hoe ik het op de client moet regelen en of ik wel of niet websockets moet gebruiken etc.

"Lokaal" pollen is toch niet meer dan een functie in een timer flikkeren en periodiek een select statement uitvoeren op de database? Niet dat dit de route is die je wilt bewandelen zoals al meerdere keren uitgelegd.

[ Voor 8% gewijzigd door ZpAz op 07-06-2013 21:27 ]

[Gomez12]

danslo schreef op vrijdag 07 juni 2013 @ 20:08:
[...]
Ik weet wat hij met pollen bedoeld, het is alleen een achterhaald concept.

Nope, het is het enige betrouwbare en werkbare concept. Je kan er fancy stuff bovenop gooien mits de client dit ondersteunt, maar de basis blijft pollen.

[danslo]

Gomez12 schreef op vrijdag 07 juni 2013 @ 20:25:
[...]

Nope, het is het enige betrouwbare en werkbare concept. Je kan er fancy stuff bovenop gooien mits de client dit ondersteunt, maar de basis blijft pollen.

Twee dingen:
- Het gaat hier niet om de client, maar om server side Node.js + socket.io. Hier komt geen polling aan te pas, is allemaal event based.
- socket.io client side is in moderne browsers gewoon een websocket, en valt voor support op oudere browsers gewoon terug op andere technieken. Waarbij long polling pas op de 3e plek komt.

[storeman]

De kern van je vraag is dus dat je in NodeJS wilt weten of er wat gewijzigd is in je database. Dit kan, zoals Vinze zegt, met Mongoose.

Het punt is dat je eigenlijk helemaal niet continu queries wil draaien op je database, om twee redenen:
1. Je loopt toch altijd iets achter de feiten aan
2. Je bent bijzonder veel queries aan het uitvoeren om realtime gedrag te benaderen


Als je toch per sé je bedachte weg wilt bewandelen, zul je ongeveer dit moeten doen:

1. Select * FROM table ORDER BY updated_at DESC LIMIT 1
2. Vergelijk de laatste updated_at met de huidge updated_at
3. Indien rij is nieuwer, teruggeven aan de clients
4. De updated_at opslaan in een globale variabele om straks weer mee te vergelijken

Als er alleen maar regels bijkomen, dan zou je dit ook kunnen oplossen met een COUNT()

Maar beter is om dit op te lossen met een trigger, vanuit andere software of vanuit MySQL.

[ Voor 29% gewijzigd door storeman op 08-06-2013 08:24 ]

[Hydra]

GlowMouse schreef op vrijdag 07 juni 2013 @ 14:28:
[...]

De database is de message bus, node.js moet hem alleen regelmatig pollen. Dat kan 10x per seconde, waarbij een resultaat vervolgens direct naar alle (long polling) clients gestuurd wordt.

Als je Socket.IO gebruikt ga je dus niet je dabtase pollen voor nieuwe berichten. Die database gebruik je alleen voor clients die later connecten om (eventueel) een message history te kunnen laten zien. Als je het goed doet stuur je alle inkomende berichten gewoon direcht door naar de andere clients en stop het bericht async in de database.

Pollen is dus gewoon NIET nodig.

ZeroXT schreef op vrijdag 07 juni 2013 @ 19:09:
Hartelijk bedankt voor alle antwoorden maar jullie begrijpen mijn vraag verkeerd.

Ik vraag hoe ik met Node.js een MySQL database kan pollen zoals je in mijn topicstart kan lezen. Ik vraag dus niet hoe ik het op de client moet regelen en of ik wel of niet websockets moet gebruiken etc.

Als je alleen wil weten hoe je een MySQL query uitvoert in Node.js had je het antwoord op die vraag sneller kunnen vinden op google.

[ Voor 28% gewijzigd door Hydra op 08-06-2013 11:00 ]

[chibimoon]

Uit oogpunt van onderhoudbaarheid, overdraagbaarheid, gewoon uit netheid. Is polling op een database niet bepaald ideaal.

Als je een chat app o.i.d. maakt. Kan je natuurlijk gewoon in de code alle clients updaten (io-socket). Zelf gebruiker accounts bijhouden e.d.. Een database is eigenlijk niet eens nodig.

Maar als je gevens wil backuppen / loggen / behouden tussen reboots, dan is een database een goede oplossing. Maar gebruik dan een ORM om je database bij te houden. Kan je b.v. bij elk inkomend bericht de database updaten.

Ik snap dat dit niet een andwoord is waar je op vraagt. Zelf ben ik een 3de jaars student Informatica op het Avans. En heb toevallig laatste blok een chatserver moeten maken met Node.js. Vandaar dat ik het niet kon laten om even te reageeren.