Node.js nos proporcionó aplicaciones web de vanguardia con conexiones bidireccionales en tiempo real en las que tanto el cliente como el servidor podían comunicarse entre sí. Un marcado contraste con el paradigma de respuesta web convencional donde solo el cliente inicia la comunicación. Es bastante similar a lo que Ruby On Rails y ASP.NET tienen para ofrecer. Desarrollado por el extremadamente rápido V8 de Google, aprovecha JavaScript, el servidor web incorporado liviano como idioma principal y tiene una gran cantidad de complementos administrados a través del Administrador de paquetes de nodos, lo que le permite a uno crear aplicaciones personalizadas para satisfacer sus necesidades. La mayor parte de esto suena como cualquier otra buena tecnología, pero viene con ciertas características que la han convertido en una opción popular entre los desarrolladores para crear un amplio espectro de aplicaciones web.
Ahora, lo que solemos pasar por alto en el debate sobre las ventajas y desventajas de los diferentes lenguajes de programación es que la mayoría de las críticas que giran en torno a ciertos problemas se derivan del uso incorrecto del lenguaje. A menudo, la crítica se centra en las prácticas seguras de escritura de códigos y en lo complicado que puede ser Node.js. Aun así, la plataforma ha existido durante un tiempo y se ha utilizado para construir una gran cantidad de servicios web sofisticados y robustos. Sin embargo, como cualquier otra plataforma, Node.js es susceptible a los problemas y problemas del desarrollador. Hoy, veremos algunos de los errores comunes que los desarrolladores nuevos de Node.js a menudo cometen.
Errores comunes que los desarrolladores de Node.js cometen [1]
1. Bloqueo del bucle de eventos
Al ser un entorno de subproceso único, no se pueden ejecutar dos partes de su aplicación en paralelo. En pocas palabras, ya que Node.js se ejecuta en un solo hilo, cualquier cosa que bloquee el bucle de eventos, bloquea todo. Aquí, la concurrencia se logra manejando las operaciones de entrada-salida de forma asincrónica. Por ejemplo, lo que permite que Node.js se centre en alguna otra parte de la aplicación es una solicitud al motor de la base de datos, desde Node.js para obtener algún documento. Sin embargo, todo lo que se necesita para bloquear el bucle de eventos es un fragmento de código enlazado a la CPU en una instancia de Node.js con muchos clientes conectados, lo que hace que todos los clientes esperen. No existe una solución clara para este problema, aparte de abordar cada caso individualmente. La idea principal es no hacer un trabajo intensivo de CPU dentro de las instancias frontales de Node.js, a las que los clientes se conectan simultáneamente.
2. Invocando devoluciones de llamada, varias veces
Se sabe que JavaScript se basa en devoluciones de llamada. En el pasado, las devoluciones de llamada eran la única forma en que los elementos asíncronos de su código se comunicaban entre sí en Node.js, hasta que aparecieron las promesas. Los desarrolladores de paquetes aún diseñan sus API en función de las devoluciones de llamada, por lo que las devoluciones de llamadas todavía se usan mucho. Un error común que los desarrolladores cometen al usar devoluciones de llamada es llamarlos más de una vez. Ver, una devolución de llamada no es el punto final de la función actual. Algunos desarrolladores optan por agregar un retorno antes de la llamada para evitar múltiples invocaciones. En la mayoría de las funciones que son asíncronas, la declaración return casi no tiene importancia y, por lo tanto, ayuda a evitar este problema. Mantenerse atento a este error es todo lo que se necesita para evitarlo.
3. Las devoluciones de llamadas no se ejecutan sincrónicamente, no espere que
La programación asincrónica con devoluciones de llamada no es exclusiva de JavaScript y Node.js. Sin embargo, tienen una gran mano en su popularidad. Estamos acostumbrados al orden predecible de ejecución con otros lenguajes de programación, donde a menos que se dé una instrucción para saltar entre las declaraciones, dos declaraciones se ejecutarán una tras otra. Aun así, a menudo se limitan a declaraciones condicionales, invocaciones de funciones y declaraciones de bucle. Ahora en JavaScript, con devoluciones de llamada, una función en particular, probablemente no se ejecutará bien hasta que finalice la tarea que está esperando. La función actual se ejecutará y ejecutará hasta el final sin detenerse. Los desarrolladores de Node.js deben asegurarse de que la siguiente tarea que tiene que suceder después de la llamada se invoque desde dentro.
4. Manejo asincrónico de errores
Parece que las devoluciones de llamada tienen la culpa de la mayoría de los problemas. Nuevamente, el problema aquí es con el comportamiento asincrónico. Vea, si el motor V8 es el corazón de su Node.js, las devoluciones de llamada son las venas que permiten un flujo equilibrado y sin bloqueo de control asincrónico a través de módulos y aplicaciones. Se introdujo el protocolo de devolución de llamada de “primer error” para garantizar que las devoluciones de llamada pudieran funcionar a escala. Ahora, JavaScript, el lenguaje detrás de él puede lanzar y atrapar excepciones en bloques try-catch. Pero, en una situación asincrónica, try-catch no se comportará como espera. Si, por ejemplo, desea proteger una gran porción de código con mucha actividad asincrónica con un gran bloque try-catch, puede que no funcione. Verá que el alcance que contiene el bloque try-catch puede haber estado fuera de contexto durante mucho tiempo para que esté quieto, capaz de detectar los errores arrojados desde el interior de la devolución de llamada. Es por eso que la mayoría de los desarrolladores de Node.Js siguen el patrón para todos los argumentos de la función de devolución de llamada, en donde el primer argumento de todas las devoluciones de llamada está reservado para un objeto de error.
5. Devolución de llamadas profundamente anidadas
O el “infierno de devolución de llamada”, como a menudo se lo denomina, no es solo un problema de Node.js. Cuanto más compleja es la tarea, peor puede ser el problema. Al anidar devoluciones de llamada de tal manera, terminamos con un código difícil de leer, propenso a errores y difícil de mantener. Por lo tanto, la mayoría usa el “infierno de devolución de llamada” como un punto clave en desacuerdo con Node.js, pero la mayoría de estas personas ven el anidamiento de devolución de llamada como inevitable. Pero ya ves, este no es el caso. Existen suficientes soluciones para mantener su código ordenado y ordenado, como el uso de módulos de control de flujo como asíncrono, promesas y generadores.
6. Uso de console.log para propósitos de depuración
En Node.js, “console.log” le permite imprimir casi cualquier cosa en la consola. Imprimirá cualquier objeto que le pase como un objeto de JavaScript literal. Acepta e imprime cualquier número arbitrario de argumentos, todos claramente separados por espacios. Entonces, entendemos por qué como desarrollador, cuando algo sale mal, es tentador solo insertar console.log en algunos lugares y depurar. Una vez que haya resuelto el problema, puede eliminar las sobras de depuración de console.log y continuar. El problema aquí es que el próximo desarrollador, que podría ser usted, podría venir y repetir el proceso. Por eso existen módulos como la depuración. En su lugar, utilice la función de depuración y simplemente déjela allí en lugar de insertar y eliminar “console.log”. Cuando el próximo desarrollador intente resolver el problema, simplemente iniciará la aplicación utilizando la variable de entorno DEBUG.
7. No hay ningún tipo de datos enteros en JavaScript
Los números son puntos flotantes en JavaScript. Por lo general, no se encuentran números lo suficientemente grandes como para forzar los límites de flotación, por lo que no esperaría que esto sea un problema. Que es exactamente cuando los errores relacionados con esto terminan sucediendo. En el momento en que se rompen los límites del flotador, los seres problemáticos y los cálculos salen mal. Además, los operadores trabajan de manera diferente con flotantes y enteros. Tener esto en cuenta podría garantizar que no tenga un problema con la forma en que se supone que funciona su función y obtenga los resultados deseados. Es posible que no esté tratando con números grandes a menudo, pero si lo hace, hay suficientes bibliotecas enteras grandes, que implementan las operaciones matemáticas necesarias en números de precisión grandes.
8. No probar religiosamente
Su solicitud no se realiza si no ha escrito ninguna prueba para ello. Está en el libro de reglas, y no hay excusa para saltarse este, considerando las muchas herramientas que existen para facilitar el proceso. En caso de que no esté seguro de cómo comenzar a escribir pruebas, puede explorar proyectos populares de Node en Github o encontrar tutoriales en línea.
9. Cero monitoreo o perfilado
No monitorear o perfilar las aplicaciones de un Nodo te deja en la oscuridad. Es muy útil tener un monitor supervisor del programa que pueda organizar su programa, ya sea que su código Node.js esté en modo de producción o ejecutándose en su entorno de desarrollo local. Hay servicios patentados que se encargan de estas cosas por usted, como los de New Relic, StrongLoop o Concurix, AppDynamics. Elija lo que elija, asegúrese de estar siempre al tanto del estado de su solicitud en todo momento.
Notas al pie
[1] https://www.cognitiveclouds.com/ …
