Cualquier anti-patrones de nodejs?

Question

¿Cuáles son los anti-patterns de node.js, qué deberías evitar al desarrollar con node.js?

Peligros como GC, cierre, manejo de errores, OO, etc.

Answer 1

patrones Anti:

ejecución sincrónica:

Evitamos toda la ejecución sincrónica, esto también se conoce como el bloqueo de IO. node.js se basa en IO no bloqueante y cualquier llamada de bloqueo única introducirá un cuello de botella inmediato.

• fs.renameSync
• fs.truncateSync
• fs.statSync
• path.existsSync
• ...

Son todos IO bloqueo de llamadas y éstos deben ser evitados.

Sin embargo existen por una razón. Pueden y solo pueden usarse durante la fase de configuración de su servidor. Es muy útil utilizar llamadas síncronas durante la fase de configuración para que pueda tener control sobre el orden de ejecución y no necesita pensar demasiado acerca de qué devoluciones de llamada se han ejecutado o no hasta el momento en que maneja su primera entrada. solicitud.

Subestimar V8:

V8 es el intérprete de JavaScript subyacente que se basa en Node.js. (¡Sí spidernode está en proceso!) V8 es rápido, su GC es muy bueno, sabe exactamente qué está haciendo. No hay necesidad de optimizar o minimizar el V8.

pérdidas de memoria:

Si usted viene de un navegador fuerte basada fondo JavaScript entonces no se preocupan mucho acerca de las pérdidas de memoria debido a que el tiempo de vida de una sola página va desde segundos hasta unas pocas horas. Donde la vida útil de un solo servidor node.js varía de días a meses.

La pérdida de memoria no es algo que piense cuando proviene de un fondo JS no del lado del servidor. Es muy importante comprender bien las fugas de memoria.

Algunos recursos:

• How to prevent memory leaks in node.js?
• Debugging memory leaks with Node.js server

Actualmente yo mismo no sé cómo preventivamente defender againts ellos.

JavaScript aplican

Todos los anti-patrones de JavaScript.En mi opinión, los principales perjudiciales son tratar JavaScript como C (escribir solo código de procedimiento) o como C#/Java (falsificación de herencia clásica).

JavaScript debe tratarse como un lenguaje OOP prototípico o como un lenguaje funcional. Yo personalmente recomiendo que use las nuevas características de ES5 y también use underscore como cinturón de herramientas. Si usa esos dos para su total ventaja, comenzará a escribir automáticamente su código en un estilo funcional que se adapte a JavaScript.

Personalmente no tengo ninguna buena recomendación sobre cómo escribir el código OOP prototípico correcto porque nunca entendí el truco.

código modular:

Node.js tiene la gran require declaración, esto significa que puede modularizar todo el código.

No hay necesidad de estado global en node.js. De hecho, necesita ir específicamente al global.foo = ... para elevarlo al estado global y esto es siempre un antipatrón.

En general, el código debe estar débilmente acoplado, EventEmitter permite un gran desacoplamiento de sus módulos y para escribir una API fácil de implementar/reemplazar.

código completo:

Cualquier cosa en el libro Code Complete 2 aplica y que no voy a repetirlo.