As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am developing a ASP.NET MVC app deployed on Azure, and looking for a library providing asynchronous transport mechanism/fallback.
After my own research, I've concluded that there are two well-known candidates - Socket.io and SignalR.
My question is simple) What's the pros and cons of them? It there any good reason to use one over the other?
thanks :)
I'd have to say that SignalR is definitely the best approach for your application. With the current build our laptops serving as servers are pushing around 350k messages/s. With the next release it will be even higher (several multiples higher judging by current tests).
Check out the main site: http://signalr.net/
The GitHub: https://github.com/SignalR/SignalR
JabbR for questions: http://jabbr.net/#/rooms/signalr
I've never used SignalR and according to what google tells me it is a replacement solution for .Net apps.
So I guess you should give it a try.
Socket.IO is awesome, I love it but I'm a noder. According to their doc there is no .net/c# bindings. Maybe their doc is not up to date.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
IndexedDB API on node.js will be very useful for some app.
Why IndexedDB is not available in node.js?
IndexedDB API does not depend on DOM, even though it does use some DOM error and event style.
It's possibly because IndexedDB is part of a different body of standards. Node.js is just ECMAScript (via Google's V8) along with their own API. Also, it may not help that IndexedDB is still in "Draft."
But, more likely it's for the same reason Node.js doesn't offer any database drivers: it's not trying to solve those problems. It's just trying to offer the APIs that assist someone who does want to solve and implement them.
And, for that, it appear at least one such project has already started: indexeddb-js. But, also have a look through IndexedDB in the NPM Registry.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I am learning Node.js and am currently studying WebSockets. As I understand it, Socket.io was intended to address inconsistent support that the various browsers had with WebSockets...If you check out caniuse WebSockets, it appears that WebSockets currently has practically full support. Can anyone explain why I should use Socket.io versus WebSockets in this case?
It handles graceful degradation for you to numerous technical alternatives to get bi-directional near-time communication flowing (web sockets, ajax long polling, flash, etc)
As of March 2013 that site lists web sockets at 61% support. This is not "practically full".
As of September 2021 that site lists web sockets at 98% support. All modern browser's support Websockets.
It handles browser inconsistencies and varying support levels for you
(these first 2 things are basically the same value created by jQuery, to put it in perspective)
It includes additional features beyond bare bones web sockets such as room support for basic publish/subscribe infrastructure and things like automatic reconnect
AFAIK it is more popular and easier to get help with than vanilla web sockets, at least at the moment.
However, just like there is VanillaJS for the jQuery haters, if you prefer using the official standard web socket APIs directly, by all means, knock yourself out.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I create a web server with Node.js. I'm using the Express framework. The database is MongoDB.
I want to host web server on a Linux machine. I don't know how to make the decision between the different Linux distributions, such as Debian, Unbuntu or RedHat.
My questions are:
What is the main difference of the different distributions?
Which factors should I take into account?
Which one is better for my requirement?
What is the main difference of the different distributions?
Nothing. (As long as running node.js is the only concern)
Which factors should I take into account?
Whether any unresolved issues are yet to be addressed by node.js.
Which one is better for my requirement?
I would consider Ubuntu, as it's popular & bugs are addressed faster due to shorter release cycle.
I'm using it in Debian. Rock solid!
In your case it also complies with the clever tip that Joachim Isaksson gave you - use whatever you're familiar with.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I could not find anywhere on google information about Spotify Apps that would say anything about the future plans of this expansion, in particular, if it would be possible to publish your own app somewhere on the future Spotify App Store or something similar to that. Does anybody know if this feature is in the future development plans of the company?
The process for getting your application published on the App Finder is here:
https://developer.spotify.com/technologies/apps/process/
Specifically, we request you submit a concept to us first so we don't end up with duplicate apps, then once that's approved the process is fairly standard - you make the app, we make sure it's good enough for the App Finder, then it gets published.
If you've already started to make an app, no matter - just submit it as a concept anyway and we can work from there.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
I'm new to Node.JS, already Googled for aswers but there is a lot of ways of doing this.
Do you have some sort of math to know when I'll need to scale my Node.JS server? And what tools you use for monitoring server performance and error track?
Thanks!
As #ThiefMaster said, this depends on your system. You need to monitor the requests for your site, the CPU load, memory footprint etc and decide if and when to add mode servers.
If you want to know more about Node.js performance read this good article: http://blog.3rd-eden.com/post/5809079469/theoretical-node-js-real-time-performance
If you need a Node.js metrics library, there are 2 ones which I can recommend: https://github.com/felixge/node-measured
https://github.com/mikejihbe/metrics
Resources:
monitoring a node.js server
I recommend monitoring your event loop and if it starts to back up more than 200ms on a regular basis, you'll need to scale.