NodeJS

• Tags:: Coding best practices, Programming Language

• De la documentación oficial:

  • El caso de uso de Node es cuando te viene muy bien la concurrencia: las operaciones son non-blocking by default async.

    • A Node.js app is run in a single process, without creating a new thread for every request. Node.js provides a set of asynchronous I/O primitives in its standard library that prevent JavaScript code from blocking and generally, libraries in Node.js are written using non-blocking paradigms, making blocking behavior the exception rather than the norm. id:: a9af4b39-5bb2-450a-8d13-4dc0e7c6873d

    • When Node.js performs an I/O operation, like reading from the network, accessing a database or the filesystem, instead of blocking the thread and wasting CPU cycles waiting, Node.js will resume the operations when the response comes back.

  • En Node hay un único hilo (en los browsers uno por pestaña) ejecutando un Event Loop, que no es más que un stack LIFO. El event loop primero mira:

    • El stack (y va ejecutando funciones de ahí). Este stack es como en cualquier lenguaje síncrono.

    • Entre el stack y el Message Queue, hay una Job Queue, que es donde van las promesas.

    • Cuando se ejecuta una función asíncrona, su callback se coloca en una Message Queue cuando corresponda (network events, de usuario, al final de un timer…), que se chequea al vaciar el stack.

const bar = () => console.log('bar')  // Cuarto
 
const baz = () => console.log('baz')  // Segundo
 
const foo = () => {
  console.log('foo')  // Primero
  setTimeout(bar, 0)
  new Promise((resolve, reject) =>
    resolve('should be right after baz, before bar')  // Tercero
  ).then(resolve => console.log(resolve))  
  baz()
}
 
foo()

	 - Además existe también process.nextTick() y otros para priorizar la ejecución de código a justo después de la función actual, antes del Message Queue.