Soy nuevo en este tipo de cosas, pero últimamente he escuchado mucho sobre lo bueno que es Node.js. Teniendo en cuenta lo mucho que 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, lo archiva.
De toda la tarea que he estado haciendo en los últimos días, obtuve la siguiente información. Nodo.js
Algunas de las fuentes con las que me he encontrado son:
Teniendo en cuenta que Node.js se puede ejecutar casi de inmediato en las instancias EC2 de Amazon , estoy tratando de entender qué tipo de problemas requieren Node.js en comparación con cualquiera de los reyes poderosos que existen como PHP , Python y Ruby . . Entiendo que realmente depende de la experiencia que uno tenga en un idioma, pero mi pregunta cae más en la categoría general de: ¿Cuándo usar un marco en particular y para qué tipo de problemas es particularmente adecuado?
Hiciste un gran trabajo al resumir lo increíble de Node.js. Mi sensación es 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 del servidor. Esta situación equivale a un ataque tarpit . Cuando usa algo como Node.js, el servidor no necesita mantener subprocesos 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 encuestas largas, Node.js es una excelente 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 simultaneidad basado en devolución de llamada, y sobresale aquí. Además, poder 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 excelente para situaciones en las que reutilizará una gran cantidad de código en la brecha cliente/servidor. El marco Meteor hace que esto sea 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 vas a reestructurar tus datos, por lo que el código que se ejecuta en el navegador puede fácilmente manipularlo y devolverlo.
Aquí hay un artículo sobre Pyramid y Long Polling, que resulta ser muy fácil de configurar con un poco de ayuda de gevent: TicTacToe and Long Polling with Pyramid .
Creo que Node.js es 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?) hace con la aplicación debe 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 incluso más de lo que es posible con un sondeo prolongado. Socket.IO recurrirá al sondeo largo como el peor de los casos y, en su lugar, utilizará sockets web o incluso Flash, si están disponibles.
Pero también debo mencionar que 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.
Además, Ryan Dahl dijo en una charla a la que asistí una vez que los puntos de referencia de Node.js rivalizan estrechamente con Nginx para las solicitudes HTTP antiguas regulares. Entonces, si construimos con Node.js, podemos servir nuestros recursos normales de manera bastante efectiva, y cuando necesitamos cosas basadas en eventos, está listo para manejarlo.
Además, todo es JavaScript todo el tiempo. Lingua Franca en toda la pila.
Para hacerlo corto:
Node.js es ideal 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 Node.js es el blog de tecnología de Mixu: Comprender el bucle de eventos de node.js.
No hay nada como Silver Bullet. Todo viene con algún costo asociado con él. Es como si comieras comida grasosa, pondrás en peligro tu salud y la comida saludable no viene con especias como la comida grasosa. Es elección individual si quieren salud o especias como en su comida. De la misma manera que Node.js considera usarse en un escenario específico. Si su aplicación no encaja en ese escenario, no debe considerarla para el desarrollo de su aplicación. Solo estoy poniendo mi pensamiento en lo mismo:
Cuándo usar Node.JS
Cuándo NO usar Node.JS
Consideración de escalabilidad con Node.JS
Alternativas a Node.JS
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 polígono y mejores consideraciones de escalabilidad.
Mi pieza: nodejs es excelente para crear sistemas en tiempo real como análisis, aplicaciones de chat, API, servidores de anuncios, etc. Demonios, hice mi primera aplicación de chat usando nodejs y socket.io en menos de 2 horas y ¡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.
Cuándo no usar
Es un servidor web muy versátil, por lo que puede usarlo donde quiera, pero probablemente no en estos lugares.
Tenga en cuenta que solo estoy bromeando. 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 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 elección de alojamiento.
Tengo un ejemplo del mundo real en el que 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 mostrara la cantidad de artículos vendidos. El cliente esperaba tener una gran cantidad de visitantes en este sitio web. Decidí hacer el contador usando Node.js y el framework Express.js .
La aplicación Node.js fue simple. Obtenga la cantidad de artículos vendidos de una base de datos de 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
En este caso, Node.js fue una excelente elección.
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.
Mi razón más para elegir Node.js para un nuevo proyecto es:
Ser capaz de hacer un desarrollo puro basado en la nube
He usado Cloud9 IDE por un tiempo y ahora no puedo imaginarme 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 necesita verificar el código en una computadora (como en casa), luego pagar en otra computadora (como en el lugar de trabajo).
Por supuesto, puede haber un IDE basado en la nube para otros lenguajes o plataformas (Cloud 9 IDE también está agregando soporte para otros lenguajes), pero usar Cloud 9 para hacer el desarrollo de Node.js es realmente una gran experiencia para mí.
Una cosa más que proporciona el nodo es la capacidad de crear múltiples instancias v8 del nodo utilizando el proceso secundario del nodo ( childProcess.fork(), cada uno de los cuales requiere 10 MB de memoria según los documentos) sobre la marcha, sin afectar 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 eliminarlos fácilmente cuando sea necesario.
He estado usando mucho el nodo y en la mayoría de las aplicaciones que construimos, requieren conexiones de servidor al mismo tiempo, por lo tanto, un tráfico de red pesado. Los marcos como Express.js y el nuevo Koajs (que eliminó el infierno de devolución de llamada) han hecho que trabajar en el nodo sea aún más fácil.
Razones para usar NodeJS:
Ejecuta Javascript, por lo que puede usar el mismo idioma en el servidor y el cliente, e incluso compartir código entre ellos (por ejemplo, para la validación de formularios o para representar vistas en cualquier extremo).
El sistema basado en eventos de un solo subproceso es rápido incluso cuando maneja muchas solicitudes a la vez, y también es simple, en comparación con los marcos tradicionales de Java o ROR de subprocesos múltiples.
El grupo cada vez mayor de paquetes accesibles a través de NPM , incluidos los módulos/bibliotecas del lado del servidor y del cliente, 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 solucionarlo 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 entorno estándar de facto en el que ejecutar herramientas relacionadas con Javascript y otras herramientas relacionadas con la web , incluidos ejecutores de tareas, minificadores, embellecedores, linters, preprocesadores, empaquetadores y procesadores de análisis.
Parece bastante adecuado para la creación de prototipos, el desarrollo ágil y la iteración rápida de productos .
Razones para no usar NodeJS:
Ejecuta Javascript, que no tiene verificación de tipos en tiempo de compilación. Para sistemas críticos de seguridad grandes y complejos, o proyectos que incluyen la colaboración entre diferentes organizaciones, un lenguaje que fomente las interfaces contractuales y proporcione verificación de tipo estático puede ahorrarle tiempo de depuración (y explosiones ) a largo plazo. (Aunque la JVM está atascada con null , use 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 marcos más antiguos se han sometido a una década de pruebas y corrección de errores, y ahora son muy estables . Npmjs.org no tiene un 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.
Infierno de devolución de llamada anidada. (Por supuesto, hay 20 soluciones diferentes para esto...)
El grupo cada vez mayor de paquetes puede hacer que un proyecto de NodeJS parezca radicalmente diferente del siguiente. Existe una gran diversidad de implementaciones debido a la gran cantidad de opciones disponibles (por ejemplo, Express/ Sails.js / Meteor / Derby ). Esto a veces puede dificultar que un nuevo desarrollador participe en un proyecto de Node. Compare eso con un desarrollador de Rails que se une a un proyecto existente: debería poder familiarizarse con la aplicación bastante rápido, porque se recomienda que todas las aplicaciones de Rails usen 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 como para hacer con Node.js que hay una pregunta de StackOverflow sobre eso con más de 80 votos a favor. No existe una forma sencilla de leer un registro a la vez de 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 comprobable. Esperemos que eventualmente podamos fusionar lo mejor de ambos mundos. Estoy ansioso por ver qué reemplazará a Node en el futuro... :)
Las razones más importantes para comenzar su próximo proyecto usando Node...
Que esperar ...
¿Quién lo usa?
Se puede usar donde
En el frente móvil, las empresas 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 se basa 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 de tráfico!
eBay lanzó ql.io, un lenguaje de consulta web para las API de HTTP, que utiliza Node.js como pila de tiempo de ejecución. Pudieron ajustar una estación de trabajo Ubuntu con calidad de desarrollador normal para manejar más de 120 000 conexiones activas por proceso de node.js, ¡con cada conexión consumiendo alrededor de 2 kB de memoria!
Walmart rediseñó su aplicación móvil para usar Node.js y empujó su procesamiento de JavaScript al servidor.
Lea más en: http://www.pixelatingbits.com/a-closer-look-at-mobile-app-development-with-node-js/
Si su aplicación se conecta principalmente a API web u otros canales io, más o menos una interfaz de usuario, node.js puede ser una elección justa para usted, especialmente si desea exprimir al máximo la escalabilidad o, si su idioma principal en la vida es javascript (o transpilers 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 que los front-enders asuman la responsabilidad de las cosas de back-end en lugar de la división típica. Otro punto de venta justificable es si su fuerza laboral está orientada a javascript para empezar.
Sin embargo, más allá de cierto punto, no puede escalar su código sin terribles trucos para forzar la modularidad, la legibilidad y el control de flujo. Sin embargo, a algunas personas les gustan esos trucos, especialmente viniendo de un fondo de javascript basado en eventos, parecen familiares o perdonables.
En particular, cuando su aplicación necesita realizar flujos sincrónicos, comienza a perder soluciones a medias que lo ralentizan considerablemente en términos de su proceso de desarrollo. Si tiene partes de computación intensiva en su aplicación, tenga cuidado 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.
Node es excelente 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 ciertamente lo extraño.
El nodo es especialmente doloroso para mantener el código que no ha visitado durante un tiempo. La información de tipo y la detección de errores en el tiempo de compilación son COSAS BUENAS. ¿Por qué tirar todo eso? ¿Para qué? Y maldita sea, cuando algo sale mal, la pila se vuelve completamente inútil.
Nodo mejor para el manejo de solicitudes concurrentes -
Entonces, comencemos con una historia. Desde los últimos 2 años, estoy trabajando en JavaScript y desarrollando una interfaz 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 ¡adivinen qué! hemos terminado. Pero en realidad no es tan fácil. Si los datos que recibimos no son correctos o hay algún error en el servidor, entonces nos atascamos y tenemos que comunicarnos con nuestros muchachos de back-end por correo o chat (a veces también en WhatsApp :)). Esto no es genial ¿Qué pasa si escribimos nuestras API en JavaScript y llamamos a esas API desde nuestro front-end? Sí, eso está muy bien porque si nos enfrentamos a algún problema en la API, podemos investigarlo. Adivina qué ! usted puede hacer esto ahora, ¿cómo? – Node está ahí para ti.
Ok, acepté que puede escribir su API en JavaScript, pero ¿y 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 API de descanso tradicional que se basa en la operación de bloqueo o en la creación de subprocesos. Supongamos que ocurren dos solicitudes simultáneas (r1 y r2), cada una de ellas requiere una operación de base de datos. Entonces, en el sistema tradicional, ¿qué sucederá?
1. Forma de espera: nuestro servidor comienza a atender la solicitud r1 y espera la respuesta de la consulta. después de completar r1 , el servidor comienza a servir a r2 y lo hace de la misma manera. Así que esperar no es una buena idea porque no tenemos mucho tiempo.
2. Forma de subprocesos: nuestro servidor creará dos subprocesos para las solicitudes r1 y r2 y cumplirá su propósito después de consultar la base de datos, por lo que es rápido. Pero consume memoria porque puede ver que comenzamos dos subprocesos y el problema aumenta cuando ambas solicitudes están consultando mismos datos, entonces usted tiene que lidiar con 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. Entonces, cuando llegue la solicitud r1 , el bucle de eventos del nodo (sí, hay un evento bucle 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 solicitud r2 y, de manera similar, registre su evento con su devolución de llamada. Cada vez que finaliza una consulta, desencadena su evento correspondiente y ejecuta su devolución de llamada hasta completarse sin ser interrumpida.
Así que no hay espera, no hay subprocesos, no hay consumo de memoria; sí, esta es una forma de nodo para servir la API de descanso.
Calzoncillos largos de asbesto...
Ayer mi titulo 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 fallar en brindarles a los lectores un servidor web, Node.js parecía, con mucho, la opción obvia. El caso se cerró antes de que se abriera.
Podría haber dado una visión muy optimista de mi experiencia con Node.js. En cambio, fui honesto acerca de 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 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 que no le dijera a un estudiante que algo era "fácil". La razón era algo obvia 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 entiende cómo resolver el problema, sino que el problema ¡Son demasiado estúpidos para entender que es fácil!
Hay trampas que no solo molestan a las personas que vienen de Python/Django, que recargan inmediatamente la fuente si cambias 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 detenga y reinicie manualmente el servidor. Este comportamiento inapropiado no solo molesta a los Pythonistas; también irrita a los usuarios nativos de Node.js que ofrecen varias soluciones alternativas. La pregunta de StackOverflow "Recarga automática de archivos en Node.js" tiene, 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, supervisor de nodos, con página de inicio en http://tinyurl.com/reactjs-node-supervisor . Este problema brinda a los nuevos usuarios una gran oportunidad de sentirse estúpidos porque pensaron que habían solucionado el problema, pero el antiguo comportamiento defectuoso 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 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 hacerle frente, tal vez con un poco de ayuda del supervisor de nodos u otra solución, pero no se vaya sintiendo que es un estúpido. Tú 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 la impresión de que "es fácil". Me corté las manos repetidamente mientras hacía que las cosas funcionaran, y no quiero suavizar las dificultades y hacerte creer que hacer que Node.js y su ecosistema funcionen bien es un asunto sencillo y si no lo es para ti también. , no sabes lo que haces. Si no se encuentra con dificultades desagradables al usar Node.js, eso es maravilloso. Si lo hace, espero que no se aleje sintiendo: "Soy estúpido, debe haber algo mal en mí". 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 crescendo ascendente 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 idiota:
Otra base de datos que parecía encajar perfectamente, y que 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 cardinal de una API que la mayoría de los buenos desarrolladores front-end entienden bastante bien. De hecho, 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 a la sintaxis del diccionario (usted quiere usar localStorage.setItem(clave, valor) o localStorage.getItem(clave), no localStorage[clave]), se implementa la semántica completa de localStorage , incluida una cuota predeterminada de 5 MB, ¿POR QUÉ? ¿Los desarrolladores de JavaScript del lado del servidor necesitan estar protegidos 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 respiro 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 administración de cookies. Un límite de 5 MB no se presta muy rápidamente al procesamiento del lado del cliente de 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 cuál es el uso razonable del espacio en disco, o si algún sitio es simplemente glotón, realmente no cuesta usted mucho y 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 saldo 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 puede señalar suavemente que cuando usted es el que escribe el código para su servidor, no necesita ninguna protección adicional para hacer que su base de datos tenga 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ñeras y los 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 dorado en el lado del cliente es bastante tonta en un servidor Node.js. (Y, para una base de datos para múltiples usuarios como la que se cubre en este Apéndice, se puede señalar, un poco dolorosamente, que eso no es 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 compartidos entre todas las cuentas de usuario juntas. ¡Eso podría volverse doloroso si se vuelve viral!) La documentación establece que la cuota es personalizable, pero un correo electrónico de hace una semana al desarrollador preguntando cómo cambiar la cuota no tiene respuesta, al igual que la pregunta de StackOverflow que pregunta lo mismo. . La única respuesta que he podido encontrar está en la fuente Github CoffeeScript, donde aparece como un segundo argumento entero opcional para un constructor. Eso es bastante fácil, y podría especificar una cuota igual al tamaño de un disco o partición. Pero además de portar una función que no tiene sentido, el autor de la herramienta ha fallado por completo en seguir una convención muy estándar de interpretar 0 como "ilimitado" para una variable o función donde un número entero especifica un límite máximo para el uso de algunos recursos. Probablemente, lo mejor que se puede hacer con esta característica incorrecta es especificar que la cuota es Infinity:
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 se disparaba innecesariamente en el pie constantemente usando JavaScript como un todo, y parte de que JavaScript se convirtió en un lenguaje respetable fue un dicho de Douglas Crockford en esencia: “JavaScript como lenguaje tiene algunas partes realmente buenas y algunas partes realmente malas. Aquí están las partes buenas. Solo olvida que hay algo más ahí.” Tal vez el ecosistema de Node.js popular desarrolle su propio "Douglas Crockford", quien dirá: "El ecosistema de Node.js es un salvaje oeste de codificación, pero hay algunas gemas reales que se pueden encontrar". Aquí hay una hoja de ruta. Estas son las áreas que debe evitar a cualquier precio. Aquí están las áreas con algunos de los más ricos paydirt que se pueden encontrar 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, 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 ecosistema Node.js de 2015 tenía varios campos minados. El ecosistema Node.js 2020 tiene múltiples paraísos”.
Puedo compartir algunos puntos sobre dónde y por qué usar el nodo js.
Inconvenientes:-
Conclusión: - Es mejor usar Nodejs para aplicaciones simples y en tiempo real ... si tiene una lógica de negocios muy grande y una funcionalidad compleja, es mejor que no use nodejs. Si desea crear una aplicación junto con el chat y cualquier funcionalidad de colaboración, el nodo se puede usar en partes específicas y debe permanecer con su tecnología de conveniencia.