Tengo una pregunta con respecto a este tema: bcrypt.compare() es asíncrono, ¿significa eso necesariamente que es seguro que se producirán retrasos?
Como no puedo poner comentarios debido a mi nivel de membresía, tuve que abrir un nuevo tema.
Mi pregunta es cuáles son las desventajas o si hay alguna para usar bcrypt.compareSync() en lugar de la versión asíncrona de bcrypt.compare() .
compareSync() definitivamente da el resultado correcto. Entonces, ¿por qué no usarlo y usar compare() envuelto en Promises? ¿Va a impedir que nodeJS sirva a otros usuarios?
La razón para usar los métodos asíncronos en lugar de los de sincronización se explica bastante bien en el archivo Léame del proyecto.
¿Por qué se recomienda el modo asíncrono sobre el modo de sincronización?
Si está utilizando bcrypt en un script simple, usar el modo de sincronización está perfectamente bien. Sin embargo, si está utilizando bcrypt en un servidor, se recomienda el modo asíncrono. Esto se debe a que el hash realizado por bcrypt requiere un uso intensivo de la CPU, por lo que la versión de sincronización bloqueará el bucle de eventos y evitará que su aplicación atienda otras solicitudes o eventos entrantes. La versión asíncrona utiliza un grupo de subprocesos que no bloquea el bucle de eventos principal.
https://github.com/kelektiv/node.bcrypt.js#por qué-es-el-modo-async-recommended-over-sync-mode
Entonces, si está usando esto en una aplicación web u otro entorno en el que no desea bloquear el hilo principal, debe usar la versión asíncrona.
Los métodos nativos de Node.js tienen métodos adjuntos de sincronización como fs.writeFileSync , crypto.hkdfSync , child_process.execSync . JavaScript en el navegador se implementa de forma asíncrona con todas las funciones nativas que requieren el bloqueo de subprocesos, pero los métodos de sincronización en Node.js en realidad bloquean los subprocesos hasta que se completa la tarea.
Al usar Callback o Promise en Node.js, si solo se ejecuta internamente la lógica asíncrona, es posible administrar tareas asíncronas mientras se continúa con otras tareas sin detener el subproceso principal (usando count para Callbak , Promise.all ).
El método de sincronización ejecuta la siguiente línea después del trabajo, por lo que es fácil identificar el orden de ejecución y codificar. Sin embargo, el hilo principal está bloqueado, por lo que no puede realizar más de una tarea a la vez.
Piensa en el siguiente ejemplo.
const syncFunc = () => { for (let i = 0; i < 100; i++) fs.readFileSync(`/files/${i}.txt`); console.log('sync done'); }; const promiseFunc = async () => { await Promise.all(Array.from({length: 100}, (_,i) => fs.promises.readFile(`/files/${i}.txt`))); console.log('promise done'); };La función de promesa finaliza mucho más rápido cuando no hay problemas para leer los 100 archivos txt.
Esta característica de sincronización se aplica igualmente a las bibliotecas hechas de lenguaje C. Si observa el siguiente código, puede ver la diferencia en la implementación en C++.
En conclusión, creo que es una cuestión de elección. No hay ningún problema al usar el método de sincronización si el código que crea es una lógica que va en un solo hilo que no importa si el hilo principal está bloqueado (como una macro simple). Sin embargo, si está creando una lógica en la que los problemas de rendimiento, como los servidores, son importantes y el subproceso principal no debe detenerse tanto como sea posible para la gestión asincrónica o de subprocesos, puede elegir Promise o Callback .