Contenido del curso

Dominios en detalle de la certificación JSNAD

Control Flow

Resumen

El dominio de control flow representa el 12% de la certificación JSNAD y exige resolver tres ejercicios extensos sobre sincronía en Node.js. Si te preparas para esta prueba, aquí entenderás cómo abordar los problemas, qué documentación dominar y por qué conviene dejar este bloque para el final.

¿Qué evalúa el dominio de control flow en JSNAD?

Este dominio mide cómo controlas la ejecución asíncrona dentro de tus programas en Node. Son tres ejercicios marcados como 2.1, 2.2 y 2.3, y cada uno suele requerir alrededor de 10 líneas de código para resolverse [0:30].

Los temas que necesitas dominar antes de presentar son varios y la documentación oficial de Mozilla Developer Network es la mejor referencia para repasarlos:

  • Callbacks tradicionales con error como primer parámetro.
  • Promises para encadenar operaciones asíncronas con menos código.
  • async y await dentro de funciones asíncronas.
  • AbortController para cancelar operaciones en curso.
  • EventEmitter como abstracción de flujo de eventos en Node [1:05].

¿Qué es control flow en Node.js? Es la forma en que organizas y controlas la ejecución de operaciones asíncronas, como peticiones HTTP, lectura de archivos o eventos, para que tu programa responda en el orden y momento correctos.

¿Por qué deberías dejar control flow para el final de la prueba?

Aunque el dominio pesa solo 12%, sus tres preguntas son largas y consumen mucho tiempo. La recomendación es resolver primero los dominios más pequeños, donde puedes sumar puntos rápido, y dejar control flow al final para no quedarte sin tiempo en preguntas que sí podías resolver [1:50].

La elección entre callbacks y promises depende de ti. Las promesas suelen producir respuestas más cortas, mientras que los callbacks requieren más código pero son explícitos. Usa el estilo con el que te sientas más cómodo bajo presión.

¿Cómo se resuelve un ejercicio típico de control flow?

El ejemplo del task 2.X muestra el patrón habitual. El enunciado entrega una función fetch ya implementada que usa HTTP get con una abstracción basada en callbacks. Esta función recibe una URL y un callback con dos parámetros: un posible error como primer argumento y la respuesta como segundo [2:35].

La instrucción es clara: la función fetch no se debe modificar. Cuando un ejercicio incluye la nota altering might result in a zero grade, tocar esa función puede convertir tu calificación en cero. Respeta siempre esa advertencia.

¿Qué debe hacer la función answer?

La función answer recibe tres argumentos, urlA, urlB y urlC, y debe consumir cada URL usando fetch, imprimir los resultados en el stream stdout, ejecutar las llamadas en el mismo tick (en paralelo) y mostrar los resultados en orden cronológico según cuál termine primero [4:10].

Si en algún punto ocurre un error, answer debe registrarlo en el stream stderr y salir inmediatamente del proceso con código 1.

¿Cómo se estructura el código de la solución?

La estrategia es crear una función auxiliar que reciba el patrón estándar de callback (error, data) y centralice el manejo de salida y errores. Después se invoca fetch tres veces pasando esa misma función [5:30].

js const { get } = require('http')

function fetch (url, cb) { // función provista, no modificar }

function answer (urlA, urlB, urlC) { function output (err, data) { if (err) { console.error(err) process.exit(1) } console.log(data) }

fetch(urlA, output) fetch(urlB, output) fetch(urlC, output) }

Como las tres llamadas a fetch se ejecutan en el mismo tick, corren en paralelo y cada una imprime cuando su respuesta llega. El orden cronológico se respeta de forma natural porque cada callback se dispara independientemente.

¿Cuál es la diferencia entre stdout y stderr? stdout es el flujo estándar de salida para resultados normales del programa. stderr es el flujo separado donde se envían errores, lo que permite distinguir y redirigir mensajes sin mezclarlos.

¿Cómo probar la solución localmente con un servidor falso?

Antes de despachar el ejercicio conviene verificar que funciona. Una forma rápida es levantar una API simulada con json-server sin instalarlo globalmente [8:20].

Los pasos son sencillos:

  1. Crear un archivo api.json con un arreglo de objetos de prueba (objeto A, objeto B, objeto C).
  2. Ejecutar npx json-server --watch api.json desde la carpeta del task.
  3. Acceder al puerto 3000 (por ejemplo, localhost:3000/a) para confirmar que sirve los datos.
  4. Ejecutar node answer en otra terminal para ver los resultados de las tres URLs.

Una vez confirmado que funciona, elimina cualquier código de prueba antes de entregar. La consigna pide proveer la función answer, no ejecutarla. Dejar invocaciones de prueba puede ensuciar la solución final.

¿Qué documentación conviene revisar antes del examen?

MDN concentra las referencias más completas para este dominio. Repasa específicamente:

  • La guía de callbacks y el patrón error-first.
  • La documentación de Promise y sus métodos como all, race y allSettled.
  • Las páginas de async function y await.
  • La referencia de AbortController para cancelar operaciones.
  • La documentación de EventEmitter en Node, que también aparece en otros dominios [10:15].

Dominar estas APIs te permite elegir la herramienta correcta para cada ejercicio y escribir menos código bajo presión. ¿Ya tienes claro con cuál estilo te sientes más cómodo, callbacks o promises? Cuéntame en los comentarios cómo planeas abordar este dominio.