Node.js Translation to Spanish - (1621 words) (Part-72)

Repository

Project Details

Node.js is an open-source, cross-platform JavaScript run-time environment that executes JavaScript code outside of a browser.

Node.js came into existence when the original developers of JavaScript extended it from something you could only run in the browser to something you could run on your machine as a standalone application.

In simple words, it's an open source execution environment for developing web applications, which is event-based, it uses the V8 engine to provide an execution environment that compiles and executes JavaScript at a higher speed. It is possible to run Node.js without any restriction on Windows, Linux and Mac OS X.

It should be noted that it is NOT a server language, this means that it executes code, so it could be understood as an interpreter.

Contribution Specifications

Node.js is currently being translated into 33 languages. I'm contributing to translate it into the Spanish language.

So far, we have managed to translate 72% of the project!

Translation Overview

In my previous contribution I worked on the Domain Module Postmortem folder, briefly based on the Domain folder that I translated on this occasion.

This module is currently deprecated. Some users agree that it doesn't matter if they are deprecated, domains are awesome if you use them right. Domains provide a way to handle multiple different IO operations as a single group and are useful for trapping errors thrown asynchronously. Using the global uncaughtException and unhandledRejection handlers don't solve the problem either. Only Domains can catch arbitrary errors like this.

Domains are useful for framework: they're a good way to separate 'user logic' from internal 'framework logic' for the purposes of failure handling and recovery.

Note that 'failure handling' is different from 'error handling'. A failure is a side effect to an Error. The user of a framework should be allowed to handle errors however they like, but sometimes you want the framework to decide how to handle the subsequent failure which resulted from that error.

For example, the framework itself might invoke a user-defined function which might branch off in unpredictable ways
and invoke various functions synchronously and/or asynchronously. In such a situation, if the user's code throws an Error, you may not want to just kill the whole server: you just want to shut down the single socket which was related to the specific action which caused the problem.

Basically, as a framework developer, domains offer you the ability to control the failure handling aspects related to code written by a third party.

If you're still not familiar about how domains are useful, you can see this Github gist.

I will add as an example of translation a section of this module as a warning/advice:

English:

Warning: Don't Ignore Errors!

Domain error handlers are not a substitute for closing down your process when an error occurs.

By the very nature of how [throw][] works in JavaScript, there is almost never any way to safely "pick up where you left off", without leaking references, or creating some other sort of undefined brittle state.

The safest way to respond to a thrown error is to shut down the process. Of course, in a normal web server, you might have many connections open, and it is not reasonable to abruptly shut those down because an error was triggered by someone else.

The better approach is to send an error response to the request that triggered the error, while letting the others finish in their normal time, and stop listening for new requests in that worker.

In this way, domain usage goes hand-in-hand with the cluster module, since the master process can fork a new worker when a worker encounters an error. For Node.js programs that scale to multiple machines, the terminating proxy or service registry can take note of the failure, and react accordingly.

Spanish:

Advertencia: ¡No ignore los errores!

Los manejadores de errores de dominio no son un sustituto para el cierre de un proceso cuando se produce un error.

Por la naturaleza misma de cómo funciona [throw][] en JavaScript, casi nunca hay alguna forma segura de "regresar a donde se quedó", sin pérdidas de referencias o crear algún otro tipo de estado frágil e indefinido.

La manera más segura de responder a un error arrojado es cerrar el proceso. Por supuesto, en un servidor web normal, es posible que tenga muchas conexiones abiertas, y no es razonable cerrarlas abruptamente porque alguien más haya provocado un error.

La mejor solución es enviar una respuesta de error a la solicitud que produjo el error, dejando que las otras terminen en su tiempo habitual y deteniendo la escucha de nuevas solicitudes en ese worker.

De esta forma, el uso de domain se hace en conjunto al módulo clúster, ya que el proceso principal puede bifurcar un nuevo worker cuando un worker encuentre un error. Para los programas de Node.js que escalan en múltiples máquinas, el proxy final o servicio de registro pueden registrar la falla y reaccionar como corresponde.