Examen nivel 4 — Node.js

Examen — preguntas inéditas

12 preguntas para validar el nivel : API REST y CRUD, autenticación y seguridad, tiempo real Socket.IO, validación, errores y tests.
Responde a todo y pulsa Corregir: aparecerán tu puntuación y las explicaciones.

4.1 · Recuerdo

1. En una API REST, ¿quién lleva la acción (crear, leer, eliminar)?

La URL, con un verbo (/getProduits, /supprimerProduit) El código de estado devuelto por el servidor Un comentario en el código fuente El método HTTP (GET, POST, PUT, DELETE) sobre una URL de recurso

URL = recurso en plural ; la acción viene del método HTTP.

4.2 · Recuerdo

2. ¿Cómo almacenar correctamente una contraseña de usuario?

Hasheándola con bcrypt (unidireccional, con sal), sin almacenarla nunca en claro En un archivo de texto junto al código En claro en la base, para recuperarla fácilmente Con un cifrado reversible casero

Se compara en la conexión sin descifrar jamás ; nunca casero.

4.3 · Recuerdo

3. ¿Qué permite un WebSocket frente a HTTP clásico?

Una conexión persistente bidireccional donde el servidor empuja al instante Páginas HTML más bonitas Un almacenamiento de archivos más rápido Peticiones más largas para escribir

Conexión abierta en continuo, mensajes en ambos sentidos.

4.1 · Aplicación

4. Salim crea un producto vía POST /api/v1/produits. ¿Qué códigos espera el front?

Ningún código, el cuerpo basta 201 si se crea, 400 si el cuerpo es inválido 200 en todos los casos, incluso en error 302 y luego 418 en todos los casos

201 tras crear, 400 si es inválido, 404 si el recurso no existe.

4.1 · Aplicación

5. La API de Salim crece : ¿dónde colocar la lógica de creación de un producto?

En la respuesta JSON misma En el archivo HTML del front En el controlador, la ruta delegando vía express.Router() Mezclada en app.js con todo lo demás

Rutas (URL) → controladores (lógica) → modelos (datos).

4.2 · Aplicación

6. Una petición llega sin token a /mon-compte (ruta protegida de Salim). ¿Respuesta?

Redirección hacia un vídeo 401 (token faltante/inválido), vía el middleware de verificación 200 con los datos igualmente 500 sin explicación

401 = no autenticado ; 403 = autenticado pero sin permiso.

4.3 · Aplicación

7. Salim quiere un chat por tienda. ¿Cómo aislar las conversaciones?

Enviar los mensajes por correo Hacer polling a la API cada 100 ms desde cada cliente Difundir cada mensaje a todos los conectados sin distinción Crear una room por tienda (socket.join) y difundir con io.to(boutique)

Rooms : quién se une a qué, difusión al perímetro correcto.

4.4 · Aplicación

8. Un cliente envía { prix: -5 } sin nom a la API de Salim. ¿Qué hacer?

Validar con el esquema (Zod/Joi) y rechazar en 400 con un mensaje claro Devolver la stack trace completa al cliente Almacenar tal cual, ya se verá luego Colgar el servidor para alertar

Validar antes de tratar ; 400 claro, nunca fuga sensible.

4.4 · Aplicación

9. ¿Dónde colocar el middleware de gestión de errores Express de Salim?

En el navegador del cliente No hace falta ninguno, try/catch basta en todas partes En último, tras las rutas, con 4 parámetros (err, req, res, next) En primero, antes de express.json()

Centralizado en último : un solo formato de error para toda la API.

4.2 · Arbitraje

10. Salim descubre su secreto JWT escrito en duro en un commit subido a Git. ¿Primer reflejo?

Copiarlo también en el README para encontrarlo Suprimir Helmet para compensar Dejarlo, nadie mira los repositorios Moverlo a variable de entorno (.env ignorado), regenerar el secreto y revocar el antiguo

Secreto fuera del código y fuera de Git ; rotación inmediata tras la exposición.

4.3 · Arbitraje

11. 40 vendedores hacen polling a la API « ¿algo nuevo? » cada segundo y el servidor se satura. ¿Arbitraje de Salim?

Hacer polling aún más a menudo para ser más tiempo real Abrir WebSockets (Socket.IO) : el servidor empuja cuando hay algo nuevo Detener toda funcionalidad en tiempo real definitivamente Devolver 200 vacío para aliviar el servidor

Empujar vía conexión abierta en vez de volver a pedir en bucle.

4.4 · Arbitraje

12. En vísperas de una entrega, Salim duda en escribir tests (« ya funciona »). ¿Qué decidir?

No testear nada y entregar rápido, ya se testeará tras el incidente Testear a mano una vez, sin automatizar nada Escribir como mínimo tests sobre las rutas críticas (400 + éxito) y relanzarlos en cada cambio Suprimir la validación para ganar tiempo

No-regresión : la suite en verde antes de cada merge libera las evoluciones.

¿Y ahora qué?

Puntuación ≥ 80 % : pase al Nivel 5 — Node.js profesional (TypeScript, rendimiento, Docker, despliegue) e industrialice sus API.
Puntuación 50-79 % : repase las secciones falladas (CRUD 4.1, auth 4.2, tiempo real 4.3, fiabilización 4.4), relea las explicaciones anteriores, y vuelva a hacer el test.
Puntuación < 50 % : vuelva a empezar el nivel desde 4.1 programando cada modelo (router, auth, chat, tests), y reintente el examen con la mente descansada.