Por qué usar mocks en desarrollo frontend
El desarrollo frontend bloqueado esperando backend es el anti-patrón más común en equipos ágiles. Tu sprint de 2 semanas pierde 5 días porque la API /users todavía no está lista. Los mocks desbloquean trabajo paralelo: frontend arma la UI contra datos falsos, backend implementa la lógica real, se integran al final.
Herramientas como MSW (Mock Service Worker) interceptan requests HTTP en desarrollo, devolviendo mocks sin tocar código productivo. JSON Server levanta una REST API completa desde un archivo db.json en 2 minutos. Faker.js genera datos aleatorios realistas (nombres, emails, direcciones) en lugar de 'Usuario 1', 'Usuario 2'.
Error crítico: mocks demasiado simplistas. Si tu mock de /users devuelve solo {id, name}, y el backend real incluye {role, permissions, lastLogin, avatar, settings}, tu frontend explota en producción. Los mocks deben replicar la estructura real o sos un kamikaze.
Estructura de respuestas REST estándar
Las APIs bien diseñadas siguen patrones reconocibles. Lista paginada: devuelve {data: [], meta: {total, page, perPage, totalPages}}. Sin meta, el frontend no puede construir paginación correcta. Objeto individual: {data: {id, ...attrs}} o directamente el objeto; ambos son válidos, pero elegí uno y mantené consistencia.
Para errores, HTTP 400/422 debe incluir {errors: [{field: 'email', message: 'ya existe'}]}. Un error genérico tipo {error: 'bad request'} es inútil, el frontend no sabe qué campo marcar en rojo. Las APIs de Stripe y GitHub son referencias de oro: cada error tiene código específico, mensaje humano y link a docs.
Timestamps siempre en ISO 8601 (2024-01-15T14:30:00Z), nunca Unix epoch o formatos locales. IDs como strings, no números (evita problemas de precisión en JavaScript con enteros >53 bits). Relaciones como /users/123/posts o incluir con ?include=posts en un sideload, nunca nested infinito que explota el payload.
Mocks para casos edge y errores
Testear solo el happy path es testear 30% de tu app. Necesitás mocks para: rate limiting (429 Too Many Requests con header Retry-After), autenticación expirada (401 con {code: 'token_expired'}), conflictos (409 cuando creás algo duplicado), validación fallida (422 con array de errores por campo).
Casos realistas que olvidás: respuestas vacías (array sin items), objetos con campos null (avatar no seteado), respuestas grandes (lista de 1000 productos), respuestas lentas (simular 3s de latency). Si tu app no maneja loading states ni empty states, los usuarios ven pantallas rotas.
MSW permite condiciones: devolver 200 las primeras 2 requests, luego 429. O retornar error 50% del tiempo para forzar que tu código maneje inconsistencia de red. En Cypress podés hacer cy.intercept('/api/users').as('getUsers').wait('@getUsers') y controlar timing exacto de cada request.
Tools y workflows de mocking profesional
Development: MSW + Faker.js es el stack ganador. MSW intercepta fetch/axios en el browser sin servidor extra, Faker genera emails realistas en lugar de test@test.com. Setup: npm i -D msw @faker-js/faker, correr npx msw init public/, crear handlers en src/mocks/handlers.ts.
Testing: Mock directo en tests unitarios (Jest/Vitest con jest.mock), pero en E2E (Cypress/Playwright) usá mocks de red reales. Playwright tiene route.fulfill() que intercepta cualquier request y devuelve JSON custom. Ventaja: testeas integración completa sin backend live.
Para equipos grandes: Postman Mock Servers o Stoplight Prism generan mocks desde OpenAPI spec. Diseñás tu API en Swagger, Prism levanta servidor HTTP con ejemplos automáticos. Backend y frontend comparten el mismo contrato, cero drift entre lo esperado y lo implementado. Cuesta setup inicial pero en equipos 10+ devs ahorra semanas de 'uy, la API cambió y no me avisaste'.