La documentación oficial del paquete mysql NPM para Node.js ( aquí ) hace la siguiente sugerencia para conectarse a una base de datos y ejecutar una consulta básica:

 var mysql = require('mysql'); var connection = mysql.createConnection({ host : 'localhost', user : 'me', password : 'secret', database : 'my_db' }); connection.connect(); connection.query('SELECT 1 + 1 AS solution', function (error, results, fields) { if (error) throw error; console.log('The solution is: ', results[0].solution); }); connection.end();

El método de conexión también toma una función de devolución de llamada opcional, y la documentación proporciona el siguiente ejemplo de ese uso (ignore los comentarios en el ejemplo a continuación; este ejemplo en realidad está tratando de demostrar algo más):

 var connection = require('mysql').createConnection({ port: 84943, // WRONG PORT }); connection.connect(function(err) { console.log(err.code); // 'ECONNREFUSED' console.log(err.fatal); // true }); connection.query('SELECT 1', function (error, results, fields) { console.log(error.code); // 'ECONNREFUSED' console.log(error.fatal); // true });

En ambos casos, el método de consulta se llama después del método de conexión y no , como cabría esperar, dentro de la devolución de llamada del método de conexión. Esto parece implicar que el método de conexión está bloqueando (es decir, sincrónico).

Así que tengo una pregunta simple, seguida de algunas preguntas más matizadas:

¿El método de connect en el módulo NPM mysql está bloqueando?

Si es así, ¿no va esto en contra de la convención Node? ¿No sería la convención hacer una consulta dentro de la devolución de llamada pasada al método de connect ?

Finalmente, si el método de conexión está bloqueando y va en contra de la convención de Node, ¿por qué los diseñadores del módulo mysql decidieron hacer el bloqueo de connect ? ¿Cuáles son las ventajas de este enfoque? Como el paquete mysql Node.js más popular, estoy seguro de que hubo una razón por la que se tomó este enfoque.