tutorial side que principiantes para node libro framework caracteristicas arquitectura javascript node.js nonblocking serverside-javascript evented-io

principiantes - node.js server-side javascript que es



¿Cuáles son algunas razones arquitectónicas para usar node.js además de la escalabilidad? (6)

El tema más común que leí sobre por qué usar node.js es para una alta escalabilidad debido a su modelo de E / S no bloqueado y con eventos. Estoy tratando de entender otros casos de uso que no sean de escalabilidad (y además de ser utilizado como un motor de javascript del lado del servidor en general).

  1. ¿Tiene node.js otros casos de uso si la escalabilidad no es una preocupación mía?
  2. Si es sí al # 1, ¿cuáles son?
  3. ¿El uso de node.js es adecuado para cualquier tipo particular de arquitecturas de aplicaciones? Por ejemplo, similar a la forma en que algunas bases de datos clave / valor (nosq - ugh odio ese término) son útiles por razones de escalabilidad.

Lo que me gusta de node.js además del modelo de E / S sin bloqueo, la escalabilidad y todas esas cosas "principales":

  • La naturaleza ligera de su marco. Los fundamentos son fáciles de aprender.
  • La comunidad de desarrolladores construye toneladas de módulos y bibliotecas útiles en github que están expandiendo el núcleo ligero de node.js y sus capacidades.
  • Es realmente fácil y rápido crear sistemas en el servidor y en tiempo real (por ejemplo, basados ​​en http o socket) sin el conocimiento de bibliotecas complejas.

Me gusta usar NodeJS para escribir el arnés de prueba porque puede escribir un apéndice / servidor / cliente realmente rápido. Y puedes conducir tu aplicación, con facilidad. Puedo realizar fácilmente una secuencia de comandos de un servidor de servicios de fondo de terceros para realizar pruebas de rendimiento en mi aplicación. También lo uso para conducir mi aplicación. Puedo realizar escenarios complejos de servidores de clientes usando setTimout para provocar que varios eventos se activen en función de la lógica que desee y probarlos a escala.

Mi razón para probar el nodo es el hecho de que es increíblemente fácil enviar datos JSON entre el servidor y el cliente para solicitudes ajax. Si usa algo como MongoDB, que también almacena datos como objeto JSON, nunca tendrá que preocuparse por traducir o analizar sus datos.

Si su sitio utiliza una gran cantidad de ajax, y está enviando sus datos como objetos JSON (en lugar de XML o texto sin formato), node.js le ahorrará un poco de esfuerzo.

Para ser precisos, creo que el motor de JavaScript del lado del servidor en general en su pregunta sería V8, mientras que según su creador, Node fue creado para "programas de red de scripting".

Basado en muchos de sus comentarios, no creo que lo vea tan ampliamente como muchos de nosotros, pero reconoce a dónde puede ir. [No puedo hablar por nadie más, es solo mi interpretación basada en los escritos y presentaciones que he visto.]

Así que aborda las cosas desde un nivel algo más bajo, hace de HTTP un ciudadano de primera clase y resulta que es realmente genial, lo que creo que es un "caso de uso" suficiente para la mayoría de nosotros. ;)

Tiene una curva de aprendizaje y no es la plataforma más estable para construir debido a su rápido desarrollo. Creo que el tiempo dirá dónde es más útil.

Por ahora, la gente lo está utilizando para aplicaciones "en tiempo real" debido a su naturaleza ligera y asíncrona, así como al desarrollo web en general, aunque IMO su punto dulce permanece con su propósito originalmente declarado.

Puedo pensar en una razón, pero no es muy profunda. Básicamente, si está desarrollando un RIA, toda su pila puede ser javascript. Eso podría tener algún valor.

Pero voy a cuestionar mi propia respuesta, a saber, la idea es que, incluso si hace que el código del lado del servidor sea más accesible para los desarrolladores del lado del cliente, aún deben entender cómo funciona la pila de su servidor. Así que todavía hay algo de aprendizaje para.