Nodejs vs SignalR: ¿por qué necesitamos javascript del lado del servidor?

90

Desde que supe de Node.js, siempre he sido fan de él. Pero hoy encontré SignalR , que proporciona un modelo alternativo asincrónico, escalable, en tiempo real para ASP.NET.

Hasta donde yo sé, la principal ventaja de Node.js sobre SignalR es compartir código entre cliente-servidor (otra ventaja debería ser que es multiplataforma), y la principal ventaja de SignalR es un marco mucho más maduro y mucho mejor soporte de herramientas (IDE). Entonces me pregunto: si SignalR está aquí, ¿ya necesitamos Node.js en Windows? ¿Hay alguna ventaja de Node.js que no conozca?

Quan Mai
fuente
27
Parece haber algo de confusión aquí. Node.js es una plataforma de desarrollo, mientras que SignalR es una biblioteca para ASP.NET. Una mejor comparación sería node.js + socket.io vs ASP.NET + SignalR. ¿Podría actualizarse esta pregunta para aclararla?
leggetter
6
Verdadero y falso, SignalR es una biblioteca para .NET.
Davidfowl

Respuestas:

107

SignalR es una alternativa viable a Socket.IO y Node.js. Sin embargo, existen otras razones para usar javascript en el servidor.

  1. Aplana la pila. Casi cualquier sitio web en estos días debe tener javascript en el navegador, y si lo usa también en el servidor, puede eliminar un idioma del lote en el que tendrá que dominar.

  2. El paso de mensajes es muy natural. JSON en todas partes! Especialmente combinado con una base de datos de documentos que usa JSON, todos los mensajes que pasan simplemente se convierten en objetos JSON. Esto hace que se reduzca la cantidad de intermediación de mensajes que debe ocurrir en todo el sistema.

  3. No es Microsoft. Personalmente, me encanta lo que Microsoft ha hecho por la comunidad de desarrolladores. Hacen herramientas fantásticas y uno de los mejores marcos y lenguajes que existen. Dicho esto, a algunas personas les encanta odiar a Microsoft.

  4. Costo. Hay muchas buenas formas de obtener herramientas de Microsoft de forma gratuita o muy barata (ediciones Express y Biz Spark). Todavía existe un costo más alto asociado con trabajar con herramientas de Microsoft. Creo que este costo compensa las ganancias de productividad en la mayoría de los casos, pero no todos están de acuerdo.

Además de lo anterior, todavía existe la historia de que no se pueden escalar solicitudes de sondeo largas en IIS debido al modelo de subprocesos. Esto tiene algo de verdad, pero con un buen diseño de código y algunos ajustes del servidor, la mayoría de las veces puede solucionar estos problemas.

Timothy Strimple
fuente
6
Leí la entrada del blog de Hanselman hanselman.com/blog/… que una aplicación de chat ASP.NET/SignalR puede servir a decenas o cientos de miles de clientes, lo cual es realmente asombroso. No profundicé para ver cómo lo hacen, pero se acerca a lo "escalable" que pueden hacer los Nodejs ...
Quan Mai
7
Si está utilizando algo como ASP.NET MVC, necesita conocer JavaScript, HTML, CSS, C # y Visual Studio. Con JavaScript en el lado del servidor, puede reducirlo a JavaScript, HTML, CSS.
Daniel Lidström
4
asp.net y .net en general no es algo exclusivo de MS. Consulte sharpdevelop y monodevelop para IDE y mono para obtener un tiempo de ejecución de .net alternativo. Esto elimina los puntos 3 y 4. Además, no creo en el paradigma de un idioma. No es difícil aprender varios idiomas a menos que esté comenzando. En cuanto a 2, crear un objeto .net desde JSON realmente no es tan difícil. Además, consulte SignalR para un sondeo prolongado y un reemplazo de comunicación en tiempo real
bbqchickenrobot
7
@ruffrey ¿Estabas diciendo? asp.net/open-source También puede auto-hospedar SignalR usando OWIN.
Timothy Strimple
4
@cbmeeks Diferentes herramientas para diferentes trabajos. Le garantizo que Walmart tiene una configuración de base de datos bastante seria (y costosa) detrás de escena, pero eso no les ha impedido optimizar su sitio web móvil con Node.js. Probablemente encontrará que eso es cierto para todas las grandes empresas que implementan Node.js. Dudo que muchos de ellos tengan algo almacenado en Mongo.
Timothy Strimple