«Shipping fast», entregar rápido, no significa escribir código de forma temeraria. Significa:
- Decisiones tomadas una vez y aplicadas en todas partes. Un patrón de validación. Una estructura de respuesta. Un formato de error.
- Desarrolladores nuevos que rinden en días. Lees un endpoint y los entiendes todos.
- Se resuelven problemas reales, no imaginarios. Construye para hoy. Optimiza cuando te topes con una restricción real.
- Las revisiones de código se centran en la lógica, no en la estructura. La consistencia elimina las discusiones de estructura.
- Los despliegues no dan miedo. Lo predecible convierte la depuración y la vuelta atrás en rutina.
Son las restricciones las que lo hacen posible. Un equipo que dedica treinta minutos a decidir cómo se estructura la validación, y luego usa esa estructura en todas partes, ha tomado una decisión y se ha ahorrado decenas de discusiones. Los equipos más rápidos con los que he trabajado eran los más consistentes.
El mito de lo «avanzado»
Todo desarrollador pasa por una fase. Descubres los microservicios, luego CQRS, luego event sourcing, luego la arquitectura hexagonal, y de pronto todo lo que has construido te parece mal hecho. Así que lo reconstruyes. Lo que era un simple endpoint POST /orders ahora necesita seis capas de abstracción y un documento de diseño más largo que tu esquema.
Esos patrones resuelven problemas reales, pero no los que tú tienes todavía. Las empresas famosas por usarlos no empezaron ahí. Empezaron con algo simple, chocaron con límites reales y evolucionaron.
El código ingenioso sienta bien, y su costo se acumula. Cada abstracción es una capa más que entender, depurar y mantener. Multiplícalo por un equipo de cinco y por dos años, y tendrás un sistema que solo entiende su autor. Cuando el autor se va, quien lo hereda hace arqueología.
La mayoría de las APIs no fracasan por no tener la arquitectura de Netflix. Fracasan porque un endpoint lo hace de una manera y otro de otra, hasta que añadir una funcionalidad exige más tiempo para entender el código existente que para escribir el nuevo.
Así que resuelve el problema que tienes delante con el código más simple que funcione, y resuélvelo igual todas las veces. A algunos, el mismo patrón repetido en cada endpoint les parece repetitivo. A los equipos con experiencia les parece libertad, porque cuando la estructura es predecible la atención se va a la lógica de negocio. Cuando choques con un límite real, añade el patrón que resuelve ese problema concreto. Para entonces entenderás por qué lo necesitas.
Cómo está estructurado
El libro sigue una sola API a lo largo de cuatro etapas.
Construirla (capítulos 1 a 6). El proyecto, la forma de una petición y de una respuesta, la integración con un proveedor externo, la autenticación, un segundo recurso que vive en la base de datos y los middleware por los que pasa cada petición.
Mantenerla viva (capítulos 7 a 13). Los errores, los reintentos seguros, el rendimiento, las colas, el trabajo programado, los tests y la monitorización.
Trabajar en ella con otras personas (capítulos 14 a 17). Las herramientas que comparte un equipo, la documentación para quienes llaman a la API, cómo cambiarla sin romperles nada y los datos que acumula.
Hacerla crecer (capítulos 18 a 21). Lo que piden los consumidores cuando lo básico ya funciona, una revisión de seguridad del conjunto, el despliegue y lo que cambia cuando un servicio se convierte en varios.
Los ejemplos de código son cortos. Cada uno muestra la idea de la que habla el párrafo que lo rodea, no la clase entera. Omiten las sentencias use y la línea declare(strict_types=1); con la que empieza cada archivo del proyecto, y // ... marca cualquier otra cosa que se haya dejado fuera. El código, con sus nombres, sus cadenas y sus mensajes, está en inglés, como en el proyecto real; solo los comentarios están traducidos. Esta edición se basa en Laravel 13 y PHP 8.5, y cuando un patrón viene directamente del framework, el texto nombra la página de la documentación de Laravel que lo describe, con su título original en inglés para que puedas buscarla.