asp.net - tutorial - Nodejs vs SignalR: ¿por qué necesitamos javascript en el lado del servidor?

node js tutorial

Question

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

Por lo que yo sé, la principal ventaja de Node.js sobre SignalR es compartir el código entre el 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 herramienta (IDE). Entonces me pregunto: si SignalR está aquí, ¿necesitamos más Node.js en Windows? ¿Hay alguna ventaja de Node.js que no sé?

Answer 1

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 todos los sitios web en estos días deben tener javascript en el navegador, y si también lo usa en el servidor, puede cortar un idioma del lote en el que tendrá que dominar.

2. El envío 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 reduce la cantidad de intermediación de mensajes que tiene que suceder en todo el sistema.

3. No es Microsoft. Personalmente, me encanta lo que Microsoft ha hecho por la comunidad de desarrollo. Ellos hacen herramientas fantásticas y uno de los mejores marcos e idiomas que existen. Dicho esto, algunas personas simplemente adoran odiar a Microsoft.

4. Costo. Existen muchas formas de obtener herramientas de Microsoft gratuitas o muy económicas (Express ediciones y Biz Spark). Todavía hay un costo mayor asociado con el trabajo con herramientas de Microsoft. Creo que este costo vale las ganancias de productividad en la mayoría de los casos, pero no todos están de acuerdo.

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