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


2195

Soy nuevo en este tipo de cosas, pero últimamente he estado escuchando mucho sobre lo bueno que es Node.js. Teniendo en cuenta cuánto me encanta trabajar con jQuery y JavaScript en general, no puedo evitar preguntarme cómo decidir cuándo usar Node.js. La aplicación web que tengo en mente es algo así como Bitly : toma algo de contenido y lo archiva.

De toda la tarea que he estado haciendo en los últimos días, obtuve la siguiente información. Node.js

  • es una herramienta de línea de comandos que se puede ejecutar como un servidor web normal y permite ejecutar programas JavaScript
  • utiliza el gran motor V8 JavaScript
  • es muy bueno cuando necesitas hacer varias cosas al mismo tiempo
  • está basado en eventos, por lo que todas las cosas maravillosas de Ajax se pueden hacer en el lado del servidor
  • nos permite compartir código entre el navegador y el backend
  • hablemos con MySQL

Algunas de las fuentes que he encontrado son:

Teniendo en cuenta que Node.js se puede ejecutar casi de forma inmediata en las instancias EC2 de Amazon , estoy tratando de entender qué tipo de problemas requieren Node.js en lugar de cualquiera de los poderosos reyes como PHP , Python y Ruby. . Entiendo que realmente depende de la experiencia que uno tenga en un idioma, pero mi pregunta se ubica más en la categoría general de: ¿Cuándo usar un marco particular y para qué tipo de problemas es particularmente adecuado?


44
Esta pregunta se está discutiendo en meta ( meta.stackoverflow.com/q/332386/497418 ).
zzzzBov

Respuestas:


1355

Hiciste un gran trabajo al resumir lo increíble de Node.js. Creo que Node.js es especialmente adecuado para aplicaciones en las que le gustaría mantener una conexión persistente desde el navegador hasta el servidor. Usando una técnica conocida como "sondeo largo" , puede escribir una aplicación que envíe actualizaciones al usuario en tiempo real. Hacer encuestas largas en muchos de los gigantes de la web, como Ruby on Rails o Django , crearía una carga inmensa en el servidor, porque cada cliente activo consume un proceso de servidor. Esta situación equivale a un ataque de tarpit . Cuando usa algo como Node.js, el servidor no necesita mantener hilos separados para cada conexión abierta.

Esto significa que puede crear una aplicación de chat basada en navegador en Node.js que casi no requiere recursos del sistema para atender a una gran cantidad de clientes. Cada vez que desee hacer este tipo de sondeo largo, Node.js es una gran opción.

Vale la pena mencionar que Ruby y Python tienen herramientas para hacer este tipo de cosas ( eventmachine y twisted , respectivamente), pero que Node.js lo hace excepcionalmente bien, y desde cero. JavaScript está excepcionalmente bien situado para un modelo de concurrencia basado en devolución de llamada, y se destaca aquí. Además, ser capaz de serializar y deserializar con JSON nativo tanto para el cliente como para el servidor es bastante ingenioso.

Espero leer otras respuestas aquí, esta es una pregunta fantástica.

Vale la pena señalar que Node.js también es ideal para situaciones en las que reutilizará una gran cantidad de código en la brecha cliente / servidor. El marco Meteor lo hace realmente fácil, y mucha gente sugiere que este podría ser el futuro del desarrollo web. Puedo decir por experiencia que es muy divertido escribir código en Meteor, y una gran parte de esto es pasar menos tiempo pensando en cómo va a reestructurar sus datos, por lo que el código que se ejecuta en el navegador puede fácilmente manipúlelo y páselo de vuelta.

Aquí hay un artículo sobre Pyramid y long-polling, que resulta muy fácil de configurar con un poco de ayuda de gevent: TicTacToe y Long Polling with Pyramid .


12
Sí, creo que es muy importante pensar que 'node.js es especialmente adecuado para aplicaciones que requieren una conexión persistente del navegador al servidor. - como programas de chat o juegos interactivos 'Si uno solo está creando una aplicación que no necesariamente necesita comunicación entre el usuario y el servidor, desarrollar con otros frameworks estaría bien y tomará mucho menos tiempo.
user482594

1
Gracias por esto ... Excelente Q y A ;-) También lo pensaría en términos de dominar una gran tecnología para el desarrollo de front-end y back-end en algunas diferentes;)
Stokedout

12
¿Por qué usar encuestas largas? ¿Qué pasó con el futuro y los enchufes ?
hitautodestruct

1
Mi respuesta corta es el proceso en segundo plano. La solicitud y la respuesta (incluida la API de descanso) se pueden lograr con cualquier otro idioma y servidor. Entonces, para aquellos que están pensando en convertir sus proyectos web en nodo. ¡Piensa de nuevo, es lo mismo! Utilice el nodo como un proceso en segundo plano, como leer correos electrónicos con imap, procesamiento de imágenes, cargar archivos en la nube o cualquier proceso largo o interminable que esté orientado principalmente a eventos ...
Vikas

409

Creo que Node.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 (¿robot o sensor?) Hace con la aplicación necesita ser visto por otros usuarios de inmediato, 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 recurrirá a las encuestas largas como el peor de los casos, y en su lugar usará sockets web o incluso Flash si están disponibles.

Pero también debo mencionar que cualquier situación en la que el código podría bloquearse debido a hilos puede abordarse mejor con Node.js. O cualquier situación en la que necesite que la aplicación esté basada en eventos.

Además, Ryan Dahl dijo en una charla que una vez asistí que los puntos de referencia de Node.js rivalizan estrechamente con Nginx para las solicitudes HTTP antiguas. Por lo tanto, si compilamos con Node.js, podemos servir nuestros recursos normales de manera bastante efectiva, y cuando necesitamos el material impulsado por eventos, está listo para manejarlo.

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


17
Solo una observación de alguien que cambia entre .Net y Node. Los diferentes idiomas para diferentes áreas del sistema ayudan mucho al cambiar de contexto. Cuando estoy mirando Javascript, estoy trabajando en el Cliente, C # significa el servidor de aplicaciones, SQL = base de datos. Al trabajar en Javascript todo el tiempo, me he encontrado confundiendo las capas, o simplemente tomando más tiempo cambiar de contexto. Es probable que esto sea un artefacto de trabajar en la pila .NET todo el día y Asintir por la noche, pero hace la diferencia.
Michael Blackburn

99
Curiosamente, la práctica de los individuos interculturales que cambian de dialecto cuando se mueven entre las culturas tradicionales y nativas se llama "cambio de código".
Michael Blackburn

1
Justo el otro día estaba pensando en cómo podría asignar diferentes colores a mis diferentes .jsarchivos de alguna manera. Verde para el lado del cliente, azul para el lado del servidor. Me sigo "perdiendo" a mí mismo.
AJB

209

Razones para usar NodeJS:

  • Ejecuta Javascript, por lo que puede usar el mismo idioma en el servidor y el cliente, e incluso compartir algún código entre ellos (por ejemplo, para la validación de formularios o para visualizar vistas en cualquier extremo).

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

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

  • Se ha convertido en el entorno estándar de facto en el que se ejecutan herramientas relacionadas con Javascript y otras herramientas relacionadas con la web , incluidos los corredores de tareas, minificadores, embellecedores, linters, preprocesadores, paquetes y procesadores analíticos.

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

Razones para no usar NodeJS:

  • Ejecuta Javascript, que no tiene verificación de tipo en tiempo de compilación. Para sistemas o proyectos grandes, complejos y críticos para la seguridad , incluida la colaboración entre diferentes organizaciones, un lenguaje que fomente las interfaces contractuales y proporcione una verificación de tipo estático puede ahorrarle tiempo de depuración (y explosiones ) a largo plazo. (Aunque la JVM está atascada null, utilice Haskell para sus reactores nucleares).

  • Sumado a eso, muchos de los paquetes en NPM son un poco crudos y aún están en rápido desarrollo. Algunas bibliotecas para frameworks más antiguos han pasado una década de pruebas y corrección de errores, y ahora son muy estables . Npmjs.org no tiene ningún 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.

  • Devolución de llamada anidada infierno. (Por supuesto, hay 20 soluciones diferentes para esto ...)

  • El grupo cada vez mayor de paquetes puede hacer que un proyecto NodeJS parezca radicalmente diferente del siguiente. Existe 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 participar en un proyecto Node. Compare eso con un desarrollador de Rails que se une a un proyecto existente: debería poder familiarizarse con la aplicación con bastante rapidez, porque se alienta a todas las aplicaciones de Rails a usar 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 extrañas para hacer con Node.js que hay una pregunta de StackOverflow con más de 80 votos a favor. No hay una manera simple de leer un registro a la vez desde un archivo CSV . Etc.

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


1
@nane Sí, creo que pueden resolver ese problema, sin embargo, debe limitarse a usar solo bibliotecas escritas en idiomas seguros o aceptar que no toda su base de código está estáticamente escrita. Pero un argumento dice: dado que debe escribir buenas pruebas para su código independientemente del idioma, su nivel de confianza debe ser igual incluso para el código escrito dinámicamente. Si aceptamos ese argumento, entonces las ventajas de la tipificación fuerte se reducen a ayudar al tiempo de desarrollo / depuración, la capacidad de prueba y la optimización .
joeytwiddle

1
@kervin, estoy de acuerdo en que algunos puntos de referencia serían geniales, pero me decepcionó lo que pude encontrar en línea. Algunos han argumentado que el rendimiento de .NET es comparable al de Node, pero que es crucial lo que realmente está haciendo. Node puede ser excelente para entregar pequeños mensajes con muchas conexiones concurrentes, pero no es tan bueno para cálculos matemáticos pesados. Una buena comparación de rendimiento necesitaría probar una variedad de situaciones.
joeytwiddle

2
@joeytwiddle, ¿no ayudarían cosas como Typecript a Node.js cuando se trata de manejar programas complejos más grandes y la comprobación de tipos estáticos?
CodeMonkey

2
@joeytwiddle para lo que vale, puede usar stillmaintained.com para determinar si un paquete npm aún se mantiene (ya que la mayoría está en github). Además, npm searchy npm showle mostrará la fecha del último lanzamiento de un paquete.
Dan Pantry el

3
Al comparar los rieles con el nodo, está confundiendo una plataforma con un marco. Rails es un marco para Ruby al igual que Sails y meteor son marcos para Javascript.
BonsaiOak

206

Para abreviar:

Node.js es muy adecuado para aplicaciones que tienen muchas conexiones concurrentes 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 Node.js es el blog de tecnología de Mixu: Comprender el ciclo de eventos Node.js .


127

Tengo un ejemplo del mundo real en el que he usado Node.js. La compañía donde trabajo tiene un cliente que quiere 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 muestre la cantidad de artículos vendidos. El cliente esperaba tener una gran cantidad de visitantes a este sitio web. Decidí hacer el contador usando Node.js y el framework Express.js .

La aplicación Node.js era simple. Obtenga la cantidad de artículos vendidos de una base de datos Redis , aumente el contador cuando se venda el artículo y sirva 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 manejarlo todo.
  2. El contador es realmente fácil de hacer en tiempo real.
  3. Node.js fue fácil de configurar.
  4. Hay muchos módulos disponibles de forma gratuita. Por ejemplo, encontré un módulo Node.js para PayPal.

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


77
¿Cómo organizas algo así? ¿Entonces tiene que configurar nodejs en el servidor de producción? En linux?
Miguel Stevens

1
Hay algunos PaaSs como nodejitsu y Heroku. O bien, puede configurar nodejs en una caja de Linux, es decir, desde Amazon EC2. ver: lauradhamilton.com/…
harry young

13
200,000 visitas en 1,814,400 segundos. No es relevante en absoluto. Incluso bash podría atender tantas solicitudes, en el servidor más lento. Scratch server. VM más lenta
Tiberiu-Ionuț Stan

105

Las razones más importantes para comenzar su próximo proyecto con Node ...

  • Todos los tipos más geniales están metidos ... así que debe ser divertido.
  • Puedes pasar el rato en el refrigerador y tener muchas aventuras de Node para presumir.
  • Eres un centavo cuando se trata de costos de alojamiento en la nube.
  • He estado allí hecho eso con Rails
  • Odias las implementaciones de IIS
  • Su antiguo trabajo de TI se está volviendo bastante aburrido y desearía estar en un nuevo y brillante Start Up.

Que esperar ...

  • Te sentirás seguro con Express sin todo el bloatware del servidor que nunca necesitaste.
  • Corre como un cohete y escala bien.
  • Lo sueñas Lo instalaste. El paquete de nodo repo npmjs.org es el ecosistema más grande de bibliotecas de código abierto en el mundo.
  • Tu cerebro se deformará en la tierra de las devoluciones de llamadas anidadas ...
  • ... hasta que aprendas a cumplir tus promesas .
  • Sequelize y Passport son tus nuevos amigos API.
  • La depuración en su mayoría de código asíncrono se volverá umm ... interesante .
  • Tiempo para que todos los Noders dominen el mecanografiado .

¿Quién lo usa?

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

18
Sí, podría haber respondido esta pregunta de la manera tradicional. Creo que estoy calificado para hacerlo, pero la mayor parte ya se ha dicho y pensé que un poco de diversión alegre rompería la monotonía. Regularmente aporto respuestas técnicas sobre otras preguntas.
Tony O'Hagan

1
las devoluciones de llamada anidadas se pueden evitar mediante el uso de generadores ES6 para el código asíncrono
refactorizado

1
@CleanCrispCode: Sí, de hecho! ES6 ha adoptado el estilo C # async/ awaitpor lo que ahora podemos implementar un código de nodo asíncrono mucho más limpio que también es compatible con try/ tradicional catch. En 2016/17, los codificadores JS están cambiando a ES6.
Tony O'Hagan

1
diez mil veces esto "Te sentirás seguro con Express sin todo el bloatware del servidor que nunca necesitaste"
Simone Poggi

60

No hay nada como Silver Bullet. Todo viene con algún costo asociado. Es como si comes 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 sus alimentos. De la misma manera, Node.js considera que se usa en un escenario específico. Si su aplicación no se ajusta a ese escenario, no debe considerarla para el desarrollo de su aplicación. Solo estoy poniendo mi pensamiento en el mismo:

Cuando usar Node.JS

  1. Si el código del lado del servidor requiere muy pocos ciclos de CPU. En otro mundo, está realizando operaciones sin bloqueo y no tiene un algoritmo pesado / trabajo que consume muchos ciclos de CPU.
  2. Si usted es de JavaScript y se siente cómodo escribiendo código Single Threaded como JS del lado del cliente.

Cuándo NO usar Node.JS

  1. Su solicitud de servidor depende del algoritmo / trabajo que consume mucha CPU.

Consideración de escalabilidad con Node.JS

  1. Node.JS en sí no utiliza todo el núcleo del sistema subyacente y es de un solo subproceso de forma predeterminada, debe escribir la lógica por su cuenta para utilizar el procesador multinúcleo y hacer que sea multiproceso.

Nodo.JS Alternativas

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


24
No estoy seguro de que "Si su solicitud del lado del servidor incluye operaciones de bloqueo como File IO o Socket IO" se enumere en "Cuándo NO usar". Si entiendo bien, una de las fortalezas de node.js es que tiene poderosos medios asincrónicos para manejar IO sin bloquear. Entonces Node.js puede ser visto como "una cura" para bloquear IO.
Ondrej Peterka

3
@OndraPeterka: Tiene razón en que Node.js es la cura para bloquear el servidor IO, sin embargo, si su controlador de solicitudes en el servidor mismo está haciendo una llamada de bloqueo a algún otro servicio web / Operación de archivos, Node.js no ayudaría aquí. No es un bloqueo de E / S solo para solicitudes entrantes al servidor, pero no para solicitudes salientes del controlador de solicitudes de la aplicación.
Ajay Tiwari

44
@ajay de nodejs.org dicen "E / S sin bloqueo", verifique su "Cuando NO" 2 y 3.
Omar Al-Ithawi

55
con la versión actual, el nodo realmente admite soporte de múltiples núcleos mediante el uso de clúster. Esto realmente aumenta el rendimiento de la aplicación Node al menos dos veces. Sin embargo, creo que el rendimiento debería ser más del doble cuando estabilizan la biblioteca en clúster.
Nam Nguyen

44
Puede usar node.js para cálculos pesados. Uso fork. Ver stackoverflow.com/questions/9546225/… . Node maneja múltiples núcleos muy bien con el clustermódulo. nodejs.org/api/cluster.html
Jess

41

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


66
Y estos paquetes son relativamente nuevos, por lo que tienen el beneficio de la retrospectiva y tienden a ajustarse a los estándares web recientes.
joeytwiddle

3
Con el debido respeto, muchos paquetes en npm son terribles, porque npm no tiene un mecanismo para calificar los paquetes . Retrospectiva de CPAN alguien?
Dan Dascalescu

Lástima que ninguna de las bibliotecas websockets pueda satisfacer las especificaciones rfc 6455. Los fanboys de node.js son sordos, tontos y ciegos cuando se da este hecho.
r3wt

1
No sé cuándo hizo el comentario, pero a partir de ahora la biblioteca ws admite esa especificación
Jonathan Gray

37

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

Editar

Han pasado varios años desde que comencé a usar nodejs y lo he usado 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 usar

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

  • Sockets solo servidores como aplicaciones de chat, aplicaciones irc, etc.
  • Redes sociales que ponen énfasis en recursos en tiempo real como geolocalización, transmisión de video, transmisión de audio, etc.
  • Manejar pequeños fragmentos de datos realmente rápido como una aplicación web de análisis.
  • Como exponer un REST solo api.

Cuando no usar

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

  • Blogs simples y sitios estáticos.
  • Solo como un servidor de archivos estático.

Tenga en cuenta que solo estoy jugando. Para servidores de archivos estáticos, apache es mejor principalmente porque está ampliamente disponible. La comunidad de nodejs se ha hecho más grande y más 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.


Los blogs simples aún pueden beneficiarse de Node.js. Para servir archivos estáticos, aún puede usar Node.js y si la carga aumenta, simplemente agregue el proxy inverso Nginx frente a él, según las mejores prácticas actuales. El servidor httpd de Apache es un dinosaurio que se está muriendo; vea esta encuesta de Netcraft .
Endrju

Yo diría lo contrario: eche un vistazo a ghost.org , se ve increíble y está construido sobre NodeJs: colaboración, edición de artículos en tiempo real. Además, crear una página simple en NodeJs, por ejemplo, usando sailsjs.org , es fácil, rápido y no necesita preocuparse por aprender ninguno de los lenguajes de programación del lado del servidor
Bery

30

Se puede usar donde

  • Aplicaciones que están altamente controladas por eventos y están fuertemente vinculadas a E / S
  • Aplicaciones que manejan una gran cantidad de conexiones a otros sistemas
  • Aplicaciones en tiempo real (Node.js fue diseñado desde cero para un tiempo real y fácil de usar).
  • Aplicaciones que hacen malabarismos con cantidades de información que fluyen hacia y desde otras fuentes
  • Alto tráfico, aplicaciones escalables
  • Aplicaciones móviles que tienen que comunicarse con la plataforma API y la base de datos, sin tener que hacer muchos análisis de datos
  • Desarrollar aplicaciones en red
  • Aplicaciones que necesitan hablar con el back-end muy a menudo

En el frente móvil, las compañías de horario estelar han confiado en Node.js para sus soluciones móviles. Mira por qué?

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

eBay lanzó ql.io, un lenguaje de consulta web para API HTTP, que utiliza Node.js como la pila de tiempo de ejecución. Pudieron sintonizar una estación de trabajo Ubuntu de calidad de desarrollador regular para manejar más de 120,000 conexiones activas por proceso node.js, ¡y cada conexión consume aproximadamente 2kB de memoria!

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

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


20

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. Los chicos de back-end nos proporcionan algunas API escritas en Java, python (no nos importa) y simplemente escribimos una llamada AJAX, ¡obtenemos nuestros datos y adivinamos qué! hemos terminado. Pero en realidad no es tan fácil, si los datos que obtenemos no son correctos o hay algún error en el servidor, entonces nos quedamos atrapados y tenemos que contactar a nuestros chicos de back-end por correo o chat (a veces también en WhatsApp :)). No es genial. ¿Qué sucede si escribimos nuestras API en JavaScript y las llamamos desde nuestro front-end? Sí, eso es bastante bueno porque si enfrentamos algún problema en la 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 el nodo para la API de descanso?

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

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

1. Modo de espera: nuestro servidor comienza a atender la r1solicitud y espera la respuesta de la consulta. Una vez completado r1, el servidor comienza a servir r2y lo hace de la misma manera. Entonces esperar no es una buena idea porque no tenemos tanto tiempo.

2. Forma de subprocesamiento : nuestro servidor creará dos subprocesos para ambas solicitudes r1y cumplirá r2su propósito después de consultar la base de datos, por lo que es genial, es rápido. Pero consume mucha memoria porque puede ver que comenzamos dos subprocesos y el problema aumenta cuando ambas solicitudes consultan los mismos datos entonces tienes que lidiar con el tipo de problemas de punto muerto. Así que es mejor que esperar, pero todavía hay problemas.

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

3. Nodeway: cuando llega la misma solicitud concurrente en el nodo, registrará un evento con su devolución de llamada y avanzará, no esperará la respuesta de la consulta para una solicitud en particular. r1Entonces, cuando llegue la solicitud, el bucle de eventos del nodo (sí, hay un bucle de eventos en el nodo que sirve para este propósito.) registre un evento con su función de devolución de llamada y avance para atender la r2solicitud y, de manera similar, registre su evento con su devolución de llamada. Cada vez que finaliza una consulta, activa su evento correspondiente y ejecuta su devolución de llamada hasta su finalización sin ser interrumpido.

Por lo tanto, sin esperas, sin subprocesos, sin consumo de memoria, sí, esta es una forma de nodo para servir API de descanso.


1
Hola anshul ¿Puede elaborar o sugerir algún recurso sobre cómo podría producirse un punto muerto en el enhebrado?
jsbisht

16

Mi otra razón para elegir Node.js para un nuevo proyecto es:

Ser capaz de hacer un desarrollo basado en la nube pura

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

Por supuesto, puede haber IDE basado en la nube para otros idiomas o plataformas (Cloud 9 IDE también está agregando soporte para otros idiomas), pero usar Cloud 9 para hacer el desarrollo de Node.js es realmente una gran experiencia para mí.


1
En realidad, Cloud9 IDE y los demás (koding el que uso) admiten casi todo tipo de lenguaje web.
Wanny Miarelli

77
¿Hablas en serio amigo? Este es el criterio para elegir una pila? :) feliz de que funcione para ti!
matanster

15

Una cosa más que proporciona el nodo es la capacidad de crear múltiples instancias v8 de nodo utilizando el proceso hijo del nodo ( childProcess.fork (), cada uno de los cuales requiere 10 MB de memoria según los documentos) sobre la marcha, por lo que no afecta el proceso principal que ejecuta el servidor. Por lo tanto, descargar un trabajo en segundo plano que requiere una gran carga del servidor se convierte en un juego de niños y podemos matarlos fácilmente cuando sea necesario.

He estado usando mucho el nodo y en la mayoría de las aplicaciones que creamos, requieren conexiones de servidor al mismo tiempo, por lo tanto, un tráfico de red pesado. Los marcos como Express.js y los nuevos Koajs (que eliminaron el infierno de devolución de llamadas) han hecho que trabajar en el nodo sea aún más fácil.


15

Colocación de calzoncillos de amianto ...

Ayer mi título con Packt Publications, Programación reactiva con JavaScript . No es realmente un título centrado en Node.js; Los primeros capítulos están destinados a cubrir la teoría, y los capítulos posteriores con mucho código cubren la práctica. Debido a que realmente no pensé que sería apropiado no darles a los lectores un servidor web, Node.js parecía, con mucho, la opción obvia. El caso se cerró incluso antes de abrirlo.

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

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

Advertencia: Node.js y su ecosistema están calientes: ¡lo suficiente como para quemarte mucho!

Cuando era asistente de maestra en matemáticas, una de las sugerencias no obvias que me dijeron fue que no le dijera a un alumno que algo era "fácil". La razón fue algo obvio en retrospectiva: si le dice 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 entienden cómo resolver el problema, sino el problema ¡son demasiado estúpidos para entender que es fácil!

Hay problemas que no solo molestan a las personas que vienen de Python / Django, que inmediatamente recarga la fuente si cambia algo. Con Node.js, el comportamiento predeterminado es que si realiza un cambio, la versión anterior continúa activa hasta el final de los tiempos o hasta que pare y reinicie el servidor manualmente. Este comportamiento inapropiado no solo molesta a los Pythonistas; También irrita a los usuarios nativos de Node.js que proporcionan varias soluciones. La pregunta de StackOverflow "Recarga automática de archivos en Node.js" tenía, en el momento de escribir este artículo, más de 200 votos a favor y 19 respuestas; una edición dirige al usuario a un script de niñera, nodo-supervisor, con página de inicio en http://tinyurl.com/reactjs-node-supervisor. Este problema ofrece a los nuevos usuarios una gran oportunidad para 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 hacer rebotar el servidor; Lo he hecho muchas veces. Y el mensaje que me gustaría dar es: “No, no eres estúpido porque este comportamiento de Node.js te mordió la espalda; es solo que los diseñadores de Node.js no vieron ninguna razón para proporcionar un comportamiento apropiado aquí. Trate de sobrellevarlo, tal vez tomando un poco de ayuda del supervisor de nodo u otra solución, pero por favor no se vaya sintiéndose estúpido. No eres el que tiene el problema; el problema está en el comportamiento predeterminado de Node.js ".

Esta sección, después de un debate, se dejó, precisamente porque no quiero dar una impresión de "Es fácil". Me corté las manos repetidamente mientras hacía que las cosas funcionaran, y no quiero suavizar las dificultades y hacer que creas que hacer que Node.js y su ecosistema funcionen bien es una cuestión sencilla y si no lo es para ti también , no sabes lo que estás haciendo. Si no encuentras dificultades desagradables con Node.js, es maravilloso. Si lo haces, espero que no te vayas sintiendo: "Soy estúpido, debe haber algo mal conmigo". No eres estúpido si experimentas sorpresas desagradables al tratar con Node.js. ¡No eres tu! ¡Es Node.js y su ecosistema!

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

Otra base de datos que parecía un ajuste perfecto, y que aún puede canjearse, es una implementación del lado del servidor del almacén de valores clave HTML5. Este enfoque tiene la ventaja fundamental de una API que la mayoría de los buenos desarrolladores front-end entienden lo suficientemente bien. Para el caso, también es una API que la mayoría de los desarrolladores front-end no tan buenos entienden lo suficientemente bien. Pero con el paquete node-localstorage, aunque no se ofrece acceso de sintaxis de diccionario (desea utilizar localStorage.setItem (clave, valor) o localStorage.getItem (clave), no localStorage [clave]), se implementa la semántica localStorage completa , incluida una cuota predeterminada de 5 MB: ¿POR QUÉ? ¿Los desarrolladores de JavaScript del lado del servidor deben protegerse de sí mismos?

Para las capacidades de la base de datos del lado del cliente, una cuota de 5 MB por sitio web es realmente una cantidad generosa y útil de espacio para respirar para que los desarrolladores puedan trabajar con ella. Podría establecer una cuota mucho más baja y aún así ofrecer a los desarrolladores una mejora inconmensurable sobre la cojera junto con la gestión de cookies. Un límite de 5 MB no se presta muy rápidamente para el procesamiento del cliente Big Data, pero hay una asignación bastante generosa que los desarrolladores ingeniosos pueden usar para hacer mucho. Pero, por otro lado, 5 MB no es una porción particularmente grande de la mayoría de los discos comprados recientemente, lo que significa que si usted y un sitio web no están de acuerdo sobre el uso razonable del espacio en disco, o si algún sitio es simplemente falso, realmente no cuesta usted mucho y no corre el peligro de un disco duro inundado a menos que su disco duro ya esté demasiado lleno.

Sin embargo, cabe señalar que cuando usted es el que escribe el código para su servidor, no necesita ninguna protección adicional para que su base de datos no supere los 5 MB de tamaño tolerable. La mayoría de los desarrolladores no necesitarán ni querrán herramientas que actúen como una niñera y que las protejan del almacenamiento de más de 5 MB de datos del lado del servidor. Y la cuota de 5 MB que es un acto de equilibrio de oro en el lado del cliente es bastante tonta en un servidor Node.js. (Y, para una base de datos para múltiples usuarios, como se cubre en este Apéndice, podría señalarse, un poco doloroso, que no son 5 MB por cuenta de usuario a menos que cree una base de datos separada en el disco para cada cuenta de usuario; eso es 5 MB compartido entre todas las cuentas de usuario juntas. Eso podría ser dolorososi te vuelves viral!) La documentación indica que la cuota es personalizable, pero hace una semana un correo electrónico al desarrollador preguntando cómo cambiar la cuota no tiene respuesta, como lo hizo la pregunta de StackOverflow. 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. Así que es bastante fácil, y podría especificar una cuota igual a un disco o tamaño de partición. Pero además de portar una característica que no tiene sentido, el autor de la herramienta no ha seguido por completo una convención muy estándar de interpretar 0 como "ilimitado" para una variable o función en la que un entero debe especificar un límite máximo para el uso de algunos recursos. Lo mejor que 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:

Douglas Crockford decía en esencia que las personas se disparaban innecesariamente en el pie constantemente usando JavaScript en su conjunto, y parte de que JavaScript se convirtiera en un lenguaje respetable decía en esencia: “JavaScript como lenguaje tiene algunas partes realmente buenas y algunas partes realmente malas. Aquí están las buenas partes. Solo olvida que hay algo más allí. Quizás el cálido ecosistema de Node.js desarrolle su propio "Douglas Crockford", quien dirá: "El ecosistema de Node.js es un codificador del Salvaje Oeste, pero hay algunas gemas reales por encontrar. Aquí hay una hoja de ruta. Aquí están las áreas para evitar a casi cualquier costo. Aquí están las áreas con algunos de los paydirt más ricos que se encuentran en CUALQUIER idioma o entorno ”.

Quizás 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 justificarse en un año, o dos, o tres, moderar bruscamente cualquier comentario sobre un ecosistema inmaduro hecho al momento de escribir este artículo. Realmente puede tener sentido en cinco años decir: “El ecosistema Node.js 2015 tuvo varios campos minados. El ecosistema 2020 Node.js tiene múltiples paraísos ”.


9

Si su aplicación ata principalmente apis web u otros canales io, brinde o tome una interfaz de usuario, node.js puede ser una elección justa para usted, especialmente si desea obtener la mayor escalabilidad o, si es su idioma principal en la vida es javascript (o transpiladores de javascript). Si crea microservicios, node.js también está bien. Node.js también es adecuado para cualquier proyecto que sea pequeño o simple.

Su principal punto de venta es que permite a los candidatos asumir la responsabilidad de las cosas de fondo en lugar de la división típica. Otro punto de venta justificable es si su fuerza laboral está orientada a JavaScript para comenzar.

Sin embargo, más allá de cierto punto, no puede escalar su código sin hacks terribles para forzar la modularidad, la legibilidad y el control de flujo. Sin embargo, a algunas personas les gustan esos hacks, especialmente porque provienen 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 sobre soluciones a medio cocer que lo ralentizan considerablemente en términos de su proceso de desarrollo. Si tiene partes de cálculo intensivo en su aplicación, pise con precaución seleccionando (solo) node.js. Tal vez http://koajs.com/ u otras novedades alivien esos aspectos originalmente espinosos, en comparación con cuando originalmente usé node.js o escribí esto.


3
Existen muchos enfoques existentes para escalar las aplicaciones de Node.js, y no parece proporcionar ninguna referencia con respecto a las reclamaciones de "soluciones a medias", "hacks terribles" y "API terribles". ¿Mente expandiéndose en esos?
Sven Slootweg

Lo dejo como un ejercicio para el lector, pero es suficiente para mirar las llamadas soluciones para el control de flujo.
matanster

2
Esa no es realmente una respuesta. Usted afirma que las soluciones existentes son "hacks terribles", pero no señala ninguno de ellos. ¿Ha considerado que simplemente podría no entender o conocer los métodos correctos para escalar las aplicaciones de Node.js?
Sven Slootweg

Actualicé un poco mi respuesta. Tal vez aún tenga quejas, pero si cree que está mal, debe comentar con detalles ... en lugar de señalar una falta de los mismos en la respuesta. Eso sería más productivo para la comunidad de la OMI.
matanster

-2

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

  1. Para aplicaciones en tiempo real como el chat, la edición colaborativa es mejor con nodejs, ya que es la base de eventos donde se disparan 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 se dirigen hacia js angular y backbone, con node es fácil interactuar con el código del lado del cliente, ya que ambas usarán datos json.
  4. Gran cantidad de complementos disponibles.

Inconvenientes: -

  1. Node admitirá la mayoría de las bases de datos, pero lo mejor es mongodb, que no admitirá combinaciones complejas y otras.
  2. Errores de compilación ... el desarrollador debe manejar todas y cada una de las excepciones si alguna aplicación de acuerdo de error deja de funcionar donde nuevamente tenemos que ir e iniciarla manualmente o usando cualquier herramienta de automatización.

Conclusión: - Nodejs es mejor usarlo para aplicaciones simples y en tiempo real ... si tiene una lógica de negocios muy grande y una funcionalidad compleja, no debería usar nodejs. Si desea crear una aplicación junto con el chat y cualquier funcionalidad colaborativa ... el nodo se puede utilizar en partes específicas y permanecer con su tecnología conveniente.


-3
  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. El nodo es especialmente doloroso para mantener el código que no ha visitado por 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 va hacia el sur, la pila de rastros a menudo es completamente inútil.


2
Si bien no obtiene la verificación en tiempo de compilación, JSDoc le permite agregar cualquier tipo de información que desee para que las cosas tengan más sentido cuando regrese. Las funciones adecuadamente descompuestas (pequeñas) también suelen ser bastante fáciles de asimilar debido a su entorno bien definido (el cierre). Los rastros de pila defectuosos a menudo se pueden resolver con una refactorización para garantizar que no está dividiendo su lógica con una devolución de llamada asincrónica en el medio. Mantener sus devoluciones de llamada asíncronas dentro del mismo cierre hace que sea fácil razonar y mantener.
Rich Remer

2
He pasado 30 años con lenguajes compilados, pero después de usarlo durante solo un año, JavaScript es ahora mi idioma de elección. Es muy productivo: puedo hacer mucho más con mucho menos código que Java C # C ++ o C. Pero es una mentalidad diferente. Las variables no tipadas son realmente una ventaja en muchos casos. JSLINT es esencial. Cuando necesita hacer cosas simultáneamente, las devoluciones de llamada asincrónicas son mucho más seguras, más fáciles y, en última instancia, más productivas que cualquier lenguaje en el que tenga que usar hilos. Y tienes que saber JavaScript de todos modos porque es el idioma del navegador.
James

Simpatizo con las preocupaciones planteadas, y noto que se han hecho algunos esfuerzos para abordarlas, aunque ciertamente no se aplican universalmente. Hay un proyecto sorprendente llamado Tern que puede proporcionar derivación de tipos a partir de análisis estáticos de código Javascript y bibliotecas. Tiene complementos para varios editores. También hay Typecript, JSDoc y BetterJS . ¡Y luego está Go , uno de los muchos lenguajes de compilación a Javascript !
joeytwiddle
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.