javascript - started - node express tutorial

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

Node es ideal para prototipos rápidos, pero nunca lo usaría de nuevo para nada complejo. Pasé 20 años desarrollando una relación con un compilador y seguro que la echo de menos.
Node es especialmente doloroso por mantener el código que no has visitado durante un tiempo. La información de tipo y la detección de errores de tiempo de compilación son BUENAS COSAS. ¿Por qué tirar todo eso? ¿Para qué? Y cuelgue, cuando algo va hacia el sur, el montón de huellas a menudo es completamente inútil.

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 dejar de 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. Node.js

es una herramienta de línea de comandos que se puede ejecutar como un servidor web normal y permite ejecutar programas de 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
nos deja hablar con MySQL

Algunas de las fuentes que he encontrado son:

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

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 en la que lo que un usuario (o robot? O sensor?) Haga con la aplicación debe ser visto por otros usuarios de inmediato. sin una página de actualización.

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 largo. Socket.IO volverá 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 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é dirigida por eventos.

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

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

Hiciste un gran trabajo al resumir lo asombroso de Node.js. Mi sensación es que Node.js es especialmente adecuado para aplicaciones donde le gustaría mantener una conexión persistente desde el navegador hasta el servidor. Usando una técnica conocida como "long-polling" , 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 se come un proceso de servidor. Esta situación equivale a un ataque de tarpit . Cuando utiliza 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 quiera hacer este tipo de sondeo largo, 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 el principio. JavaScript está excepcionalmente bien situado para un modelo de concurrencia basado en devolución de llamada, y sobresale 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 de Meteor lo hace realmente fácil, y muchas personas están sugiriendo 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 reestructurar sus datos, por lo que el código que se ejecuta en el navegador puede fácilmente manipularlo y devolvérselo.

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 .

Las razones más importantes para comenzar su próximo proyecto usando Nodo ...

Todos los tipos más geniales están en eso ... así que debe ser divertido.
Puedes quedarte en la nevera y tener muchas aventuras de Node para presumir.
Usted es un centavo cuando se trata de costos de alojamiento en la nube.
Ya lo he hecho con rieles.
Odias las implementaciones de IIS
Su antiguo trabajo de TI se está volviendo bastante aburrido y desearía estar en un nuevo Start Up brillante.

Que esperar ...

Te sentirás seguro con Express sin todos los programas de software que nunca has necesitado.
Corre como un cohete y escala bien.
Lo sueñas Lo instalaste. El paquete de nodos repo packages es el ecosistema más grande de bibliotecas de código abierto del mundo.
Tu cerebro tendrá tiempo deformado en la tierra de devoluciones de llamadas anidadas ...
... hasta que aprendas a cumplir tus Promises .
Sequelize y Passport son tus nuevos amigos API.
Depurando código principalmente asíncrono obtendrá umm ... interesante .
Tiempo para que todos los Noders dominen a Typescript.

¿Quién lo usa?

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

Mi única razón más para elegir Node.js para un nuevo proyecto es:

Ser capaz de hacer puro desarrollo basado en la nube.

He usado Cloud9 IDE por un tiempo y ahora no puedo imaginar 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 casa), luego haga la verificación en otra computadora (como en el lugar de trabajo).

Por supuesto, puede que haya un IDE basado en la nube para otros idiomas o plataformas (el IDE de Cloud 9 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í.

Mi artículo: nodejs es excelente para crear sistemas en tiempo real como análisis, aplicaciones de chat, apis, servidores de anuncios, etc. Demonios, 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 utilizado para hacer muchas cosas diferentes, incluidos servidores de archivos estáticos, análisis simple, aplicaciones de chat y mucho más. Esta es mi opinión sobre cuándo usar nodejs

Cuándo usar

Al hacer el sistema que pone é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, 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, así que puedes usarlo donde quieras, pero probablemente no en estos lugares.

Sencillos blogs y sitios estáticos.
Al igual que un servidor de archivos estáticos.

Ten en cuenta que solo estoy matando. Para los servidores de archivos estáticos, apache es mejor principalmente porque está ampliamente disponible. La comunidad de nodejs ha crecido y se ha hecho más madura a lo largo de los años y es seguro decir que nodejs se puede usar en cualquier lugar si tiene su propia opción de alojamiento.

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

Cuándo usar Node.JS

Si el código del lado de su servidor requiere muy pocos ciclos de CPU. En otro mundo, está realizando una operación sin bloqueo y no tiene un algoritmo / trabajo pesado que consuma muchos ciclos de CPU.
Si eres de Javascript en segundo plano y cómodo para escribir el código de subprocesamiento único como el lado del cliente JS.

Cuando NO usar Node.JS

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

Consideración de escalabilidad con Node.JS

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

Alternativas Node.JS

Hay otras opciones para usar en lugar de Node.JS, sin embargo, Vert.x parece ser bastante prometedor y tiene muchas características adicionales como poligoto y mejores consideraciones de escalabilidad.

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.

Para hacerlo corto:

Node.js es 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 Node.js es el blog de tecnología de Mixu: Cómo entender el bucle de eventos node.js.

Puede ser utilizado donde

Aplicaciones que son 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 (Node.js fue diseñado desde cero para que sea fácil de usar).
Aplicaciones que combinan montones de información transmitida a otras fuentes.
Alto tráfico, aplicaciones escalables.
Aplicaciones móviles que tienen que hablar con la plataforma y la base de datos de la plataforma, sin tener que hacer muchos análisis de datos
Construir aplicaciones en red
Aplicaciones que necesitan hablar con el back-end muy a menudo.

En el frente de Mobile, las empresas de mayor audiencia han confiado en Node.js para sus soluciones móviles. Echa un vistazo 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 las API HTTP, que utiliza Node.js como la pila de tiempo de ejecución. ¡Pudieron sintonizar una estación de trabajo Ubuntu con calidad de desarrollador para manejar más de 120,000 conexiones activas por proceso node.js, con cada conexión consumiendo alrededor de 2kB de memoria!

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

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

Razones para usar NodeJS:

Funciona con Javascript, por lo que puede usar el mismo idioma en el servidor y el cliente, e incluso compartir un código entre ellos (por ejemplo, para validar el formulario o para mostrar vistas en cualquier extremo).
El sistema controlado por eventos de un single-threaded es fast 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 múltiples hilos.
El grupo cada vez mayor de packages accesibles a través de NPM , incluidas las bibliotecas / módulos 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 se encuentran convenientemente alojados en github, donde a veces puede informar un problema y encontrarlo solucionado en unas 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 se ejecutan las herramientas relacionadas con Javascript y otras herramientas relacionadas con la web , incluidos los 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 rápida iteración de productos .

Razones para no usar NodeJS:

Ejecuta Javascript, que no tiene verificación de tipo de tiempo de compilación. Para sistemas grandes, complejos , críticos para la seguridad , o proyectos que incluyen la colaboración entre diferentes organizaciones, un lenguaje que fomenta las interfaces contractuales y proporciona una verificación de tipos estática puede ahorrarle tiempo de depuración (y explosiones ) a largo plazo. (Aunque la JVM está bloqueada con un 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 correcciones de errores, y ahora son muy estables . Npmjs.org no tiene ningún mecanismo para calificar los paquetes , lo que ha llevado a una proliferación de paquetes que hacen más o menos lo mismo, de los cuales ya no se mantiene un gran porcentaje.
Callback anidado infierno. (Por supuesto que 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 ). A veces, esto puede hacer que sea más difícil para un nuevo desarrollador saltar a un proyecto Node. Contrasta eso con un desarrollador de Rails que se une a un proyecto existente: debería poder familiarizarse con la aplicación bastante rápido, ya que 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 con más de 80 votos a favor. No hay 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 demostrable. Esperemos que eventualmente podamos fusionar lo mejor de ambos mundos. Estoy ansioso por ver qué reemplazará a Node en el futuro ... :)

Tengo un ejemplo del mundo real en el que he usado Node.js. La empresa en la que trabajo tiene un cliente que quería tener un sitio web HTML simple y estático. 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 espera tener una gran cantidad de visitantes a este sitio web. Decidí hacer el contador utilizando 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 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

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 podido manejarlo todo.
El contador es realmente fácil de hacer en tiempo real.
Node.js fue fácil de configurar.
Hay muchos módulos disponibles gratis. Por ejemplo, encontré un módulo Node.js para PayPal.

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

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 al proceso principal que ejecuta el servidor. Por lo tanto, la descarga de 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 los nodos y en la mayoría de las aplicaciones que creamos, requieren conexiones de servidor al mismo tiempo, por lo tanto, un gran tráfico de red. Frameworks como Express.js y los nuevos Koajs (que eliminaron el infierno de devolución de llamada) han hecho que trabajar en nodo sea aún más fácil.

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 web front end y lo estoy disfrutando. Los usuarios 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 estamos obteniendo no son correctos o si hay algún error del servidor, nos quedamos atascados y tenemos que contactar a nuestros empleados de back-end por correo o chatear (a veces también en WhatsApp :)). no es genial ¿Qué pasa si escribimos nuestras API''s en JavaScript y las llamamos desde nuestra interfaz? Sí, eso es bastante bueno porque si nos enfrentamos a cualquier problema en la API podemos verlo. Adivina qué ! Puedes hacer esto ahora, ¿cómo? - Node está ahí para ti.

Ok estuvo de acuerdo en que puedes escribir tu API en JavaScript, pero ¿qué pasa si estoy de acuerdo con el problema anterior? ¿Tienes 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.

Regresemos a nuestro sistema tradicional de API de descanso que se basa en la operación de bloqueo o en la hebra. 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 atender la solicitud de 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. Modo 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 se enfría de manera rápida. Pero consume mucha memoria porque puede ver que iniciamos dos subprocesos. El problema también aumenta cuando ambas solicitudes realizan consultas. Los mismos datos entonces tienes que lidiar con el tipo de interbloqueo. Así que es mejor que esperar, pero todavía hay problemas.

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

3. Nodeway: cuando la misma solicitud simultánea entra en el nodo, entonces registrará un evento con su devolución de llamada y avanzará, no esperará la respuesta de la consulta para una solicitud en particular. Por lo tanto, cuando la solicitud de r1 produce, se produce 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 petición r2 y registre 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 no hay que esperar, no hay subprocesos, no hay consumo de memoria, sí, es una manera inteligente de servir la API de descanso.

Donning asbestos longjohns ...

Ayer mi título con Publicaciones Packt, Programación Reactiva con JavaScript . No es realmente un título centrado en Node.js; los primeros capítulos tienen la intención de cubrir la teoría, y luego los capítulos de código pesado cubren la práctica. Debido a que realmente no pensé que sería apropiado no darle a los lectores un servidor web, Node.js parecía la opción más obvia. El caso se cerró antes de que incluso se abrió.

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 los puntos malos que encontré.

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

Advertencia: Node.js y su ecosistema son lo suficientemente calientes como para quemarte gravemente.
Cuando era asistente de 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 dice a la gente que algo es fácil, alguien que no ve una solución puede terminar sintiéndose (incluso 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 muy fácil.
Hay errores que no solo molestan a las personas que vienen de Python / Django, que inmediatamente recargan la fuente si cambias algo. Con Node.js, el comportamiento predeterminado es que si realiza un cambio, la versión anterior seguirá activa hasta el final de los tiempos o hasta que detenga y reinicie el servidor manualmente. Este comportamiento inapropiado no solo molesta a los pitonistas; también irrita a los usuarios nativos de Node.js que proporcionan varias soluciones. La pregunta de "Recarga automática de archivos en Node.js" tiene, al momento de escribir este artículo, más de 200 upvotes 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 . Este problema ofrece a los nuevos usuarios una gran oportunidad de sentirse estúpidos porque pensaron que habían solucionado el problema, pero el comportamiento antiguo y defectuoso no cambia por completo. Y es fácil olvidarse de rebotar el servidor; Lo he hecho varias veces. Y el mensaje que me gustaría transmitir 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 lidiar con eso, quizás necesite un poco de ayuda de un supervisor de nodo u otra solución, pero por favor, no se vaya sintiendo que es 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 poco de debate, se dejó, precisamente porque no quiero dar una impresión de "Es fácil". Me corté las manos repetidamente mientras conseguía que las cosas funcionaran, y no quiero suavizar las dificultades y configúrense para creer que lograr que Node.js y su ecosistema funcionen bien es un asunto directo y, si no es sencillo para usted también, no sabe lo que está haciendo. Si no te encuentras con dificultades detestables al usar Node.js, eso es maravilloso. Si lo haces, espero que no te alejes sintiendo: "Soy estúpido, debe haber algo malo conmigo". No eres estúpido si experimentas sorpresas desagradables relacionadas con Node.js. ¡No eres tu! ¡Es Node.js y su ecosistema!

El Apéndice, que realmente no quería después del creciente aumento 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 morónico:

Otra base de datos que parecía un ajuste perfecto, y que aún se puede canjear, es una implementación del lado del servidor del almacén de valor-clave 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. En este sentido, 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, mientras que no se ofrece el acceso de sintaxis del diccionario (quiere 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 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 que los desarrolladores puedan trabajar con él. Podría establecer una cuota mucho más baja y seguir ofreciendo a los desarrolladores una mejora incalculable con respecto a la limitación junto con la administración de cookies. Un límite de 5MB no se presta muy rápidamente para el procesamiento del lado del cliente de Big Data, pero hay un margen muy generoso que los desarrolladores de recursos pueden usar para hacer mucho. Pero, por otro lado, 5MB no es una parte 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 con el uso razonable del espacio en disco, o si algún sitio es simplemente tonto, realmente no cuesta nada. mucho y no está en peligro de tener un disco duro inundado a menos que su disco duro ya estuviera demasiado lleno. Tal vez estaríamos mejor si el saldo fuera un poco más o menos, pero en general es una solución decente para abordar la tensión intrínseca para un contexto del lado del cliente.
Sin embargo, puede señalarse suavemente que cuando usted es el único código de escritura para su servidor, no necesita ninguna protección adicional para que su base de datos tenga 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 una niñera y que las protejan de almacenar 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 un poco tonta en un servidor Node.js. (Y, para una base de datos para múltiples usuarios, como se describe en este Apéndice, puede señalarse, de manera poco dolorosa, que eso no es 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 se vuelve viral!) La documentación indica que la cuota es personalizable, pero un correo electrónico hace una semana al desarrollador que pregunta cómo cambiar la cuota no tiene respuesta, al igual que la pregunta que hace 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. Así que eso 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 función que no tiene sentido, el autor de la herramienta no siguió completamente una convención muy estándar de interpretar 0 que significa "ilimitado" para una variable o función donde un número entero debe especificar un límite máximo para el uso de algunos recursos. Lo mejor que puedes hacer con esta característica mala 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:

Las personas se dispararon innecesariamente a sí mismas constantemente utilizando JavaScript en su totalidad, y parte de JavaScript se convirtió en un lenguaje respetable, fue un dicho de Douglas Crockford, en esencia, “JavaScript como lenguaje tiene algunas partes realmente buenas y otras realmente malas. Aquí están las partes buenas. Solo olvida que todo lo demás está allí ". Tal vez el ecosistema de Node.js crezca en su propio " Douglas Crockford ", quien dirá:" El ecosistema de Node.js es un Salvaje Oeste de codificación, pero se encuentran algunas gemas reales. . Aquí hay una hoja de ruta. Aquí están las áreas para evitar a casi cualquier costo. Aquí están las áreas con algunas de las prendas de vestir más ricas que se pueden encontrar en CUALQUIER idioma o entorno ”.
Quizás alguien más pueda tomar esas palabras como un desafío, seguir el ejemplo de Crockford y escribir "las partes buenas" y / o "las partes mejores" para Node.js y su ecosistema. ¡Me 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, para atenuar de manera aguda cualquier comentario sobre un ecosistema inmaduro realizado en el momento de escribir este artículo. Realmente podría tener sentido en cinco años decir: “El ecosistema de Node.js 2015 tenía varios campos minados. El ecosistema Node.js 2020 tiene múltiples paraísos ”.

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

Para aplicaciones en tiempo real como chat, edición colaborativa, mejor vamos con nodejs, ya que es la base de eventos donde se activan eventos y datos para los clientes desde el servidor.
Simple y fácil de entender ya que es la base javascript donde la mayoría de las personas tienen una idea.
La mayoría de las aplicaciones web actuales se dirigen hacia js y backbone angulares, con nodo es fácil interactuar con el código del lado del cliente ya que ambos usarán datos json.
Muchos complementos disponibles.

Inconvenientes: -

El nodo admitirá la mayoría de las bases de datos, pero lo mejor es mongodb, que no admite uniones complejas y otras.
Los desarrolladores de errores de compilación ... deben manejar todas y cada una de las excepciones de otra manera si cualquier aplicación de acuerdo de error dejará de funcionar donde otra vez tenemos que ir y comenzar manualmente o con cualquier herramienta de automatización.

Conclusión: - Es mejor utilizar 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 puede usarse en partes específicas y el resto debe ir con su tecnología de conveniencia.

Si su aplicación se basa principalmente en aplicaciones web u otros canales de io, proporcione o tome una interfaz de usuario, node.js puede ser una buena elección para usted, especialmente si desea exprimir la mayor escalabilidad o, si su idioma principal es javascript (o transpilers de javascript de tipo). Si construyes microservicios, node.js también está bien. Node.js también es adecuado para cualquier proyecto que sea pequeño o simple.

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

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 provenientes de un fondo de javascript impulsado por eventos, parecen familiares o perdonables.

En particular, cuando su aplicación necesita realizar flujos sincrónicos, comienza a sangrar sobre soluciones a medio cocer que le ralentizan considerablemente en términos de su proceso de desarrollo. Si tiene partes de computación intensivas en su aplicación, pise con precaución seleccionando (solo) node.js. Tal vez Koajs u otras novedades alivien esos aspectos espinosos originales, en comparación con cuando originalmente usé node.js o escribí esto.