Cómo decidir cuándo usar Node.js?

Creo Nodo.js es el más adecuado para aplicaciones en tiempo real: juegos en línea, herramientas de colaboración, salas de chat, o cualquier cosa donde lo que un usuario(o robot? ¿o sensor?) does con la aplicación necesita ser visto por otros usuarios inmediatamente, sin una actualización de página.

También debo mencionar que Socket.IO en combinación con Node.js reducirá su latencia en tiempo real aún más de lo que es posible con un sondeo largo. Socket.IO volverá a las encuestas largas como el peor de los casos, y en su lugar, use sockets web o incluso Flash si están disponibles.

Pero también debo mencionar que casi cualquier situación en la que el código pueda bloquearse debido a subprocesos se puede abordar mejor con Node.js. O cualquier situación en la que necesite que la aplicación esté basada en eventos.

También, Ryan Dahl dijo en una charla que una vez asistí a que el Nodo.los puntos de referencia de js rivalizan estrechamente con Nginx para las solicitudes HTTP antiguas regulares. Así que si construimos con Nodo.js, podemos servir a nuestros recursos normales bastante efectivamente, y cuando necesitamos las cosas impulsadas por eventos, está listo para manejarlas.

Además todo es JavaScript todo el tiempo. Lingua Franca en toda la pila.

Razones para usar NodeJS:

• Ejecuta Javascript, por lo que puede usar el mismo lenguaje en el servidor y el cliente, e incluso compartir algo de código entre ellos (por ejemplo, para la validación de formularios o para renderizar vistas en ambos extremos.)

• El sistema basado en eventos de subproceso único es rápido incluso cuando se manejan muchas solicitudes a la vez, y también es simple, en comparación con los subprocesos múltiples tradicionales Java o ROR marco.

• El siempre creciente grupo de paquetes accesibles a través de NPM, incluyendo bibliotecas/módulos del lado del cliente y del servidor, así como herramientas de línea de comandos para el desarrollo web. La mayoría de ellos están convenientemente alojados en github, donde a veces se puede informar de un problema y encontrar solucionado en cuestión de horas! Es bueno tener todo bajo un mismo techo, con informes de problemas estandarizados y fácil bifurcación.

• Se ha convertido en el estándar de facto entorno en el que ejecutar Herramientas relacionadas con Javascript y otras herramientas relacionadas con la web, incluidos corredores de tareas, minificadores, embellecedores, linters, preprocesadores, bundlers y procesadores de análisis.

• Parece bastante adecuado para la creación de prototipos, el desarrollo ágil y la iteración rápida del producto.

Razones no para usar NodeJS:

• Ejecuta Javascript, que no tiene verificación de tipo en tiempo de compilación. Para grandes, complejos sistemas críticos para la seguridad, o proyectos que incluyen la colaboración entre diferentes organizaciones, un lenguaje que fomenta interfaces contractuales y proporciona comprobación de tipo estático puede ahorrarle algo de tiempo de depuración (y explosiones) a largo plazo. (Aunque la JVM está atascada con null, así que por favor use Haskell para sus reactores nucleares.)

• Sumado a eso, muchos de los paquetes en NPM son un poco raw, y todavía bajo rapid desarrollo. Algunas bibliotecas para frameworks antiguos han pasado por una década de pruebas y corrección de errores, y son muy estables por ahora. Npmjs.org no tiene mecanismo para calificar paquetes, lo que ha llevado a una proliferación de paquetes que hacen más o menos lo mismo, de los cuales un gran porcentaje ya no se mantiene.

• Un infierno anidado de devolución de llamada. (Por supuesto hay 20 soluciones diferentes a esto...)

• El creciente grupo de paquetes puede hacer que un proyecto de NodeJS aparezca radicalmente diferente del siguiente. Hay una gran diversidad en las implementaciones debido a la gran cantidad de opciones disponibles (por ejemplo, Express/Sails.js/Meteor/Derby ). Esto a veces puede hacer que sea más difícil para un nuevo desarrollador saltar en un proyecto de nodo. Contrasta eso con un desarrollador Rails que se una a un proyecto existente: debería ser capaz de familiarizarse con la aplicación bastante rápido, porque todas las aplicaciones Rails son se alienta a utilizar una estructura similar.

• Tratar con archivos puede ser un poco molesto. Las cosas que son triviales en otros idiomas, como leer una línea de un archivo de texto, son lo suficientemente raras como para hacer con Node.js que hay una pregunta de StackOverflow sobre eso con más de 80 votos positivos. No existe una forma sencilla de leer un registro a la vez desde un archivo CSV. Sucesivamente.

Me encanta NodeJS, es rápido y salvaje y divertido, pero me preocupa que tenga poco interés en demostrable-corrección. Esperemos que finalmente podamos fusionar lo mejor de ambos mundos. Estoy ansioso por ver qué reemplazará a Node en el futuro... :)

Para abreviar:

.js es muy adecuado para aplicaciones que tienen muchas conexiones simultáneas y cada solicitud solo necesita muy pocos ciclos de CPU, porque el bucle de eventos (con todos los demás clientes) se bloquea durante la ejecución de una función.

Un buen artículo sobre el bucle de eventos en el nodo.js is Mixu's tech blog: Understanding the node (en inglés).bucle de eventos js.

Tengo un ejemplo del mundo real donde he usado Node.js. La empresa donde trabajo consiguió un cliente que quería tener un sitio web HTML estático simple. Este sitio web es para vender un artículo usando PayPal y el cliente también quería tener un contador que muestra la cantidad de artículos vendidos. Cliente espera tener una gran cantidad de visitantes a este sitio web. Decidí hacer el contador usando Nodo.js and the Express.js framework.

El Nodo.la aplicación js era simple. Conseguir la cantidad de artículos vendidos de una base de datos Redis, aumenta el contador cuando se vende el artículo y sirve el valor del contador a los usuarios a través de la API .

Algunas razones por las que elegí usar Node.js en este caso

1. es muy ligero y rápido. Ha habido más de 200000 visitas en este sitio web en tres semanas y los recursos mínimos del servidor han sido capaces de manejar todo.
2. El contador es muy fácil de hacer para ser en tiempo real.
3. Nodo.js fue fácil de configurar.
4. Hay muchos módulos disponibles de forma gratuita. Por ejemplo, encontré un Nodo.módulo js para PayPal.

En este caso, Node.js fue una elección increíble.

Las razones más importantes para iniciar su próximo proyecto usando Node ...

• Todos los tíos más guays están en ello ... así que debe ser divertido.
• Puedes pasar el rato en el refrigerador y tener muchas aventuras de nodos de las que presumir.
• Usted es un estafador cuando se trata de costos de alojamiento en la nube.
• He hecho eso con Rails
• Odias las implementaciones de IIS
• Su antiguo trabajo de TI se está volviendo bastante aburrido y desea estar en un nuevo comienzo brillante Hasta.

Qué esperar ...

• Se sentirá seguro y protegido con Express sin todo el software de relleno del servidor que nunca necesitó.
• Corre como un cohete y escama bien.
• Lo sueñas. Tú lo instalaste. El paquete de nodos repo npmjs.org es el mayor ecosistema de bibliotecas de código abierto del mundo.
• Tu cerebro se deformará en el tiempo en la tierra de las devoluciones de llamada anidadas ...
• ... hasta que aprendas a mantener tu Promesas.
• Sequelizey Passport son tus nuevos amigos de la API.
• Depurar mayormente código asincrónico obtendrá umm ... interesante .
• Tiempo para que todos los Noders dominen Typescript.

¿Quién lo usa?

• PayPal, Netflix, Walmart, LinkedIn, Groupon, Uber, GoDaddy, Dow Jones
• He aquí por qué cambiaron a Node.

No hay nada como Silver Bullet. Todo viene con algún costo asociado con él. Es como si comieras alimentos grasos, comprometerás tu salud y los alimentos saludables no vienen con especias como los alimentos grasos. Es una elección individual si quieren salud o especias como en su comida. Nodo de la misma manera.js consider to be used in specific scenario. Si su aplicación no encaja en ese escenario, no debe considerarlo para el desarrollo de su aplicación. Sólo estoy poniendo mi pensamiento en el mismo:

Cuándo usar Node.JS

1. Si su código del lado del servidor requiere muy pocos ciclos de cpu. En otro mundo, está haciendo una operación sin bloqueo y no tiene un algoritmo/Trabajo pesado que consume muchos ciclos de CPU.
2. Si usted es de Javascript back ground y cómodo en la escritura de código Único Subproceso al igual que el lado del cliente JS.

Cuándo NO usar Node.JS

1. Su solicitud de servidor depende del gran consumo de CPU algoritmo / Trabajo.

Consideración de escalabilidad con Node.JS

1. Nodo.JS en sí no utiliza todo el núcleo del sistema subyacente y es un solo subproceso por defecto, usted tiene que escribir la lógica por su cuenta para utilizar el procesador de múltiples núcleos y hacerlo multi subproceso.

Nodo.JS Alternatives

Hay otra opción para usar en lugar de Node.JS however Vert.x parece ser bastante prometedor y tiene muchas características adicionales como polygot y mejores consideraciones de escalabilidad.

Otra gran cosa que creo que nadie ha mencionado sobre Nodo.js es la increíble comunidad, el sistema de gestión de paquetes (npm) y la cantidad de módulos que existen que puedes incluir simplemente incluyéndolos en tu paquete.archivo json.

Mi pieza: nodejs es ideal para hacer sistemas en tiempo real como análisis, aplicaciones de chat, api, servidores de anuncios, etc. Diablos, hice mi primera aplicación de chat usando nodejs y socket.io menos de 2 horas y eso también durante el examen semana!

Editar

Han pasado varios años desde que comencé a usar nodejs y lo he utilizado para hacer muchas cosas diferentes, incluidos servidores de archivos estáticos, análisis simples, aplicaciones de chat y mucho más. Esta es mi opinión sobre cuándo usar nodejs

Cuándo use

Al hacer un sistema que ponga énfasis en la concurrencia y la velocidad.

• Sockets solo servidores como aplicaciones de chat, aplicaciones de irc, etc.
• Redes sociales que ponen énfasis en recursos en tiempo real como geolocalización, flujo de vídeo, flujo de audio, etc.
• Manejar pequeños trozos de datos muy rápido como una aplicación web de análisis.
• Como exponer una api solo REST.

Cuándo no usar

Es un servidor web muy versátil para que puede usarlo donde quiera, pero probablemente no en estos lugares.

• Blogs simples y sitios estáticos.
• Como un servidor de archivos estáticos.

Ten en cuenta que solo soy quisquilloso. Para servidores de archivos estáticos, apache es mejor principalmente porque está ampliamente disponible. La comunidad de nodejs se ha vuelto más grande y madura a lo largo de los años y es seguro decir que nodejs se puede usar en casi todas partes si tiene su propia opción de alojamiento.

Se puede utilizar donde

• Aplicaciones que están altamente impulsadas por eventos y están fuertemente vinculadas a E/S
• Aplicaciones que manejan un gran número de conexiones a otros sistemas
• Aplicaciones en tiempo real (Nodo.js fue diseñado desde cero para tiempo real y para ser fácil utilizar.)
• Aplicaciones que hacen malabares con montones de información en streaming hacia y desde otras fuentes
• Alto tráfico, aplicaciones escalables
• Aplicaciones móviles que tienen que hablar con la API de la plataforma & base de datos, sin tener que hacer muchos datos análisis
• Construir aplicaciones en red
• Aplicaciones que necesitan hablar con el back-end muy a menudo

En el frente móvil, las empresas de prime time han confiado en Node.js para sus soluciones móviles. Echa un vistazo a por qué?

LinkedIn es un usuario destacado. Toda su pila móvil está construida en el nodo.js. Pasaron de ejecutar 15 servidores con 15 instancias en cada máquina física, a solo 4 instancias – que puede manejar el doble de tráfico!

EBay lanzado ql.io, un lenguaje de consulta web para las API HTTP, que utiliza Node.js como la pila de tiempo de ejecución. Fueron capaces de ajustar una estación de trabajo Ubuntu regular de calidad de desarrollador para manejar más de 120,000 conexiones activas por nodo.proceso js, con cada conexión consumiendo aproximadamente 2kB de memoria!

Walmart rediseñó su aplicación móvil para usar Node.js y empujó su procesamiento JavaScript al servidor.

Leer más en: http://www.pixelatingbits.com/a-closer-look-at-mobile-app-development-with-node-js /

Nodo mejor para el manejo simultáneo de solicitudes -

Entonces, comencemos con una historia. Desde los últimos 2 años estoy trabajando en JavaScript y desarrollando front end web y lo estoy disfrutando. Back end chicos nos proporcionan algunas API escritas en Java, python (no nos importa) y simplemente escribir una llamada AJAX, obtener nuestros datos y adivinar qué ! hemos terminado. Pero en realidad no es tan fácil, si los datos que estamos obteniendo no son correctos o hay algún error del servidor, entonces nos quedamos atascados y tenemos que contactar con nuestra espalda terminar chicos por correo o chat(a veces en WhatsApp también :).) Esto no es genial. ¿Qué pasa si escribimos nuestras API en JavaScript y llamamos a esas API desde nuestro front end ? Sí, eso es bastante genial porque si nos enfrentamos a cualquier problema en API podemos investigarlo. ¡Adivina qué ! puedes hacer esto ahora, ¿cómo ? - Node está ahí para ti.

Ok acordó que puede escribir su API en JavaScript, pero qué pasa si estoy de acuerdo con el problema anterior. ¿Tiene alguna otra razón para usar node para la API rest ?

Así que aquí está el comienza la magia. Sí, tengo otras razones para usar node para nuestras API.

Volvamos a nuestro sistema API REST tradicional que se basa en la operación de bloqueo o en el subproceso. Supongamos que se producen dos solicitudes simultáneas (r1 y r2), cada una de ellas requiere la operación de la base de datos. Así que en el sistema tradicional lo que sucederá :

1. Modo de espera: Nuestro servidor comienza a servir la solicitud r1 y espera la respuesta de la consulta. después de completar r1, el servidor comienza a servir r2 y lo hace de la misma manera. Así que esperar no es una buena idea porque no tenemos mucho tiempo.

2. Threading Way: Nuestro servidor creará dos subprocesos para ambas solicitudes r1 y r2 y servirá a su propósito después de consultar la base de datos tan cool que es rápido.Pero es el consumo de memoria, ya que se puede ver que empezamos dos subprocesos también aumenta el problema cuando tanto la solicitud está consultando los mismos datos, entonces usted tiene que lidiar con el tipo de bloqueo de los problemas . Así que es mejor que esperar, pero aún así los problemas están ahí.

Ahora aquí está, cómo lo hará node:

3. Nodeway: Cuando la misma solicitud concurrente viene en el nodo, entonces registrará un evento con su devolución de llamada y avanzará, no esperará la respuesta de la consulta para un determinado request.So cuando la solicitud r1 viene entonces el bucle de eventos del nodo (sí, hay un bucle de eventos en el nodo que sirve para este propósito.) registrar un evento con su función de devolución de llamada y seguir adelante para servir r2 solicitud y registrar de manera similar su evento con su devolución de llamada. Cada vez que una consulta finaliza, activa su evento correspondiente y ejecuta su devolución de llamada hasta su finalización sin ser interrumpida.

Así que sin esperas, sin hilos , sin consumo de memoria – sí, este es nodeway para servir la API rest.

Mi una razón más para elegir Nodo.js para un nuevo proyecto es:

Ser capaz de hacer desarrollo puro basado en la nube

He usado Cloud9 IDE durante un tiempo y ahora no puedo imaginar sin él, cubre todos los ciclos de vida del desarrollo. Todo lo que necesita es un navegador y puede codificar en cualquier momento en cualquier lugar y en cualquier dispositivo. No es necesario que registres el código en una computadora(como en casa), y luego compres en otra computadora (como en el lugar de trabajo).

Por supuesto, hay tal vez el IDE basado en la nube para otros idiomas o plataformas (Cloud 9 IDE está agregando soporte para otros idiomas también), pero usando Cloud 9 para hacer Nodo.js developement es realmente una gran experiencia para mí.

Una cosa más que node proporciona es la capacidad de crear múltiples instanes v8 de node utilizando el proceso hijo de node( ChildProcess.fork () cada uno requiere 10mb de memoria según los documentos) sobre la marcha, por lo que no afecta al proceso principal que ejecuta el servidor. Así que descargar un trabajo en segundo plano que requiere una gran carga de servidor se convierte en un juego de niños y podemos eliminarlos fácilmente cuando sea necesario.

He estado usando nodo mucho y en la mayoría de las aplicaciones que construimos, requieren conexiones de servidor en el al mismo tiempo, por lo tanto, un tráfico de red pesado. Frameworks como Express.js y el nuevo Koajs (que eliminó callback hell) han hecho que trabajar en node sea aún más fácil.

Poniéndose asbestos longjohns...

Ayer mi título con Packt Publications, Programación reactiva con JavaScript . No es realmente un Nodo.título centrado en js; los primeros capítulos están destinados a cubrir la teoría, y los capítulos más tarde cargados de código cubren la práctica. Porque realmente no pensé que sería apropiado no dar a los lectores un servidor web, Nodo.js parecía de lejos la elección obvia. The case was closed before it was even opened.

I podría haber dado una visión muy optimista de mi experiencia con Node.js. En cambio, fui honesto sobre los puntos buenos y los puntos malos que encontré.

Permítanme incluir algunas citas que son relevantes aquí:

Advertencia: Nodo.js y su ecosistema son calientes hot lo suficientemente calientes como para quemarte gravemente!

Cuando era asistente de un maestro en matemáticas, una de las sugerencias no obvias que me dijeron fue no decirle a un estudiante que algo era "fácil."La razón fue algo obvio en retrospectiva: si le dices a la gente que algo es fácil, alguien que no ve una solución puede terminar sintiéndose (aún más) estúpido, porque no solo no saben cómo resolver el problema, sino que el problema que son demasiado estúpidos para entender es fácil.

Hay gotchas que no solo molestan a las personas que vienen de Python / Django, que inmediatamente recargan el código fuente si cambia algo. Con Nodo.js, el comportamiento predeterminado es que si realiza un cambio, la versión anterior continúa activo hasta el final del tiempo o hasta que detenga y reinicie manualmente el servidor. Este comportamiento inapropiado no solo molesta a los pythonistas; también irrita al Nodo nativo.usuarios de js que proporcionan varias soluciones. La pregunta de StackOverflow " Recarga automática de archivos en el nodo.js " tiene, en el momento de escribir este artículo, más de 200 votos positivos y 19 respuestas; una edición dirige al usuario a un script de niñera, node-supervisor, con página de inicio en http://tinyurl.com/reactjs-node-supervisor . Esto el problema ofrece a los nuevos usuarios una gran oportunidad de sentirse estúpidos porque pensaron que habían solucionado el problema, pero el viejo comportamiento con errores no ha cambiado por completo. Y es fácil olvidarse de rebotar el servidor; lo he hecho varias veces. Y el mensaje que me gustaría dar es, " No, no eres estúpido porque este comportamiento de Nodo.js mordió la espalda; es solo que los diseñadores de Nodo.js no vio ninguna razón para proporcionar un comportamiento apropiado aquí. Trate de hacer frente a ella, tal vez tomando un poco ayuda de node-supervisor u otra solución, pero por favor no te vayas sintiendo que eres estúpido. Usted no es el que tiene el problema; el problema está en el nodo.comportamiento predeterminado de js."

Esta sección, después de un debate, se dejó en, precisamente porque no quiero dar una impresión de "Es fácil."Me corto las manos repetidamente mientras hago que las cosas funcionen, y no quiero suavizar las dificultades y hacerte creer que conseguir Nodo.js y su ecosistema para funcionar bien es un asunto sencillo y si no es sencillo para ti también, no sabes lo que estás haciendo. Si no te encuentras con dificultades desagradables usando Node.js, eso es maravilloso. Si lo haces, espero que no te vayas sintiendo, " Soy estúpido-debe haber algo mal en mí."No eres estúpido si experimentas sorpresas desagradables tratando con Node.js. ¡No eres tú! Es Node.js y su ecosistema!

El Apéndice, que realmente no quería después del levantamiento crescendo en los últimos capítulos y la conclusión, habla de lo que pude encontrar en el ecosistema, y proporcionó una solución para el literalismo idiota:

Otra base de datos que parecía un ajuste perfecto, y aún puede ser canjeable, es una implementación del lado del servidor del almacén de clave-valor HTML5. Este enfoque tiene la ventaja fundamental de una API que la mayoría de los buenos desarrolladores de front-end entienden lo suficientemente bien. Para el caso, también es una API que la mayoría de front-end no tan bueno los desarrolladores entienden bastante bien. Pero con el paquete node-localstorage, mientras que el acceso dictionary-syntax no se ofrece (desea usar localStorage.setItem (clave, valor) o localStorage.getItem (key), no localStorage [key]), se implementa la semántica completa de localStorage, incluyendo una cuota predeterminada de 5MB - ¿POR QUÉ? ¿Los desarrolladores de JavaScript del lado del servidor necesitan estar protegidos de sí mismos?

Para las capacidades de base de datos del lado del cliente, una cuota de 5 MB por sitio web es realmente una generosa y cantidad útil de espacio de respiración para permitir que los desarrolladores trabajen con él. Podría establecer una cuota mucho más baja y aún ofrecer a los desarrolladores una mejora inconmensurable sobre cojear junto con la administración de cookies. Un límite de 5MB no se presta muy rápidamente al procesamiento de Big Data del lado del cliente, pero hay una asignación realmente generosa que los desarrolladores ingeniosos pueden usar para hacer mucho. Pero por otro lado, 5MB no es una porción particularmente grande de la mayoría de los discos comprados en cualquier momento recientemente, lo que significa que si y un sitio web no está de acuerdo sobre lo que es el uso razonable del espacio en disco, o algún sitio es simplemente hoggish, realmente no le cuesta mucho y usted no está en peligro de un disco duro inundado a menos que su disco duro ya estaba demasiado lleno. Tal vez estaríamos mejor si el equilibrio fuera un poco menos o un poco más, pero en general es una solución decente para abordar la tensión intrínseca para un contexto del lado del cliente.

Sin embargo, se podría señalar suavemente que cuando usted es el que escribe código para su servidor, no necesita ninguna protección adicional para hacer que su base de datos sea más de un tamaño tolerable de 5 MB. La mayoría de los desarrolladores no necesitarán ni querrán herramientas que actúen como niñera y los protejan del almacenamiento de más de 5 MB de datos del lado del servidor. Y la cuota de 5MB que es un acto de equilibrio dorado en el lado del cliente es más bien un poco tonto en un nodo.servidor js. (Y, para una base de datos para múltiples usuarios como se trata en este Apéndice, se podría señalar, un poco dolorosamente, que eso es no 5MB por cuenta de usuario a menos que cree una base de datos separada en el disco para cada cuenta de usuario; eso es 5MB compartido entre todas las cuentas de usuario juntas. ¡Eso podría ser doloroso si te vuelves viral!) La documentación indica que la cuota es personalizable, pero un correo electrónico de hace una semana al desarrollador preguntando cómo cambiar la cuota no ha sido contestado, al igual que la pregunta de StackOverflow pidiendo lo mismo. La única respuesta que he podido encontrar está en la fuente de Github CoffeeScript, donde aparece como un segundo argumento entero opcional para un constructor. Por lo que es bastante fácil, y se podría especificar una cuota igual a un tamaño de disco o partición. Pero además de portar una característica que no tiene sentido, el autor de la herramienta ha fallado completamente en seguir una convención muy estándar de interpretar 0 como "ilimitado" para una variable o función donde un entero es especificar un límite máximo para algún uso de recursos. Lo mejor que se puede hacer con este error es probablemente especificar que la cuota es Infinito:

if (typeof localStorage === 'undefined' || localStorage === null)
  {      
  var LocalStorage = require('node-localstorage').LocalStorage;
  localStorage = new LocalStorage(__dirname + '/localStorage',
    Infinity);
  }

Intercambiando dos comentarios en orden:

La gente innecesariamente se disparó en el pie constantemente usando JavaScript como un todo, y parte de JavaScript se hizo lenguaje respetable fue un Douglas Crockford diciendo en esencia, "JavaScript como un lenguaje tiene algunas partes realmente buenas y algunas partes realmente malas. Aquí están las partes buenas. Olvida que hay algo más."Tal vez el Nodo caliente.js ecosistema crecerá su propio "Douglas Crockford, "quién dirá," El Nodo.js ecosystem es un salvaje Oeste de codificación, pero hay algunas joyas reales que se encuentran. Aquí hay una hoja de ruta. Estas son las áreas a evitar a casi cualquier costo. Aquí están las áreas con algunos de los más ricos paydirt que se encuentran en CUALQUIER idioma o entorno."

Tal vez alguien más pueda tomar esas palabras como un desafío, y seguir el ejemplo de Crockford y escribir "las partes buenas" y / o "las mejores partes" para Node.js y su ecosistema. ¡Compraría una copia!

Y dado el grado de entusiasmo y las horas de trabajo en todos los proyectos, puede estar justificado en un año, o dos, o tres, moderar bruscamente cualquier comentario sobre un ecosistema inmaduro hecho en el momento de escribir este artículo. Realmente puede tener sentido en cinco años decir: "El Nodo de 2015.js ecosystem had several minefields. El Nodo 2020.js ecosystem tiene múltiples paraísos."

Si su aplicación principalmente ata api web, u otros canales de e / s, dar o tomar una interfaz de usuario, nodo.js puede ser una elección justa para usted, especialmente si desea exprimir la mayor escalabilidad, o, si su lenguaje principal en la vida es javascript (o transpilers de javascript de clases). Si crea microservicios, node.js también está bien. Nodo.js también es adecuado para cualquier proyecto que sea pequeño o simple.

Su principal punto de venta es que permite que los front-enders se responsabilicen del back-end cosas en lugar de la típica división. Otro punto de venta justificable es si su fuerza de trabajo está orientada a Javascript para empezar.

Más allá de cierto punto, sin embargo, no puede escalar su código sin terribles hacks para forzar la modularidad, la legibilidad y el control de flujo. Sin embargo, a algunas personas les gustan esos hacks, especialmente viniendo de un fondo de javascript impulsado por eventos, parecen familiares o perdonables.

En particular, cuando su aplicación necesita realizar flujos síncronos, comienza a sangrar más de soluciones a medio cocinar que lo ralentizan considerablemente en términos de su proceso de desarrollo. Si tiene partes intensivas en computación en su aplicación, pise con precaución el nodo de selección (solo).js. Tal vez http://koajs.com / u otras novedades alivian esos aspectos originalmente espinosos, en comparación con cuando originalmente usé node.js or escribió esto.

Puedo compartir algunos puntos donde y por qué usar el nodo js.

1. Para aplicaciones en tiempo real como chat,edición colaborativa mejor vamos con nodejs ya que es base de eventos donde disparar eventos y datos a los clientes desde el servidor.
2. Simple y fácil de entender, ya que es la base de javascript donde la mayoría de la gente tiene idea.
3. La mayoría de las aplicaciones web actuales van hacia angular js&backbone, con node es fácil interactuar con el código del lado del cliente, ya que ambos usarán datos json.
4. Muchos plugins disponibles.

Inconvenientes: -

1. El nodo soportará la mayoría de las bases de datos, pero lo mejor es mongodb que no soportará uniones complejas y otras.
2. Errores de compilación...el desarrollador debe manejar todas y cada una de las excepciones de otra manera si cualquier aplicación accord error dejará de funcionar donde de nuevo tenemos que ir e iniciarlo manualmente o utilizando cualquier herramienta de automatización.

Conclusión:- Nodejs mejor para usar en tiempo simple y real aplicación..si tiene una lógica de negocios muy grande y una funcionalidad compleja mejor no debe usar nodejs. Si desea construir una aplicación junto con el chat y cualquier funcionalidad colaborativa.. node se puede usar en partes específicas y remain debe ir con su tecnología de conveniencia.

1. Node es ideal para prototipos rápidos, pero nunca lo volvería a usar para nada complejo. Pasé 20 años desarrollando una relación con un compilador y seguro que lo extraño.

2. Node es especialmente doloroso para mantener el código que no has visitado durante un tiempo. La información de tipo y la detección de errores en tiempo de compilación son BUENAS COSAS. ¿Por qué tirar todo eso? Para qué? Y dang, cuando algo se va al sur de la pila rastros bastante a menudo completamente inútil.