Stack y herramientas

Stack principal. Ecosistema maduro, Eloquent para el día a día y una comunidad que resuelve el 90% de los problemas habituales antes de que los tengas.

Donde el rendimiento manda. Mantiene la aplicación en memoria entre peticiones y elimina el coste de arranque del ciclo tradicional de PHP. En rutas de consulta muy solicitadas, la diferencia se nota.

Para servicios donde interesa el tipado fuerte y el ecosistema enterprise. Spring cubre seguridad, persistencia y configuración sin tener que montarlo a mano.

No es una elección, es una realidad de muchos sistemas en producción. Saber moverse en una base legacy sin romperla es una habilidad en sí misma.

Backend en JavaScript, sobre todo en proyectos web donde el resto del stack ya vive en el mismo lenguaje.

Frontend, scripting y herramientas. TypeScript siempre que el proyecto vaya a durar más de un par de meses.

Framework principal de frontend. La Composition API mantiene la lógica ordenada según crece el componente.

Sobre Vue, para aplicaciones de gestión: extranets, intranets y paneles. Aporta un catálogo de componentes consistente y evita rehacer el sistema de diseño en cada superficie.

En proyectos donde el equipo o el cliente ya lo tiene. Componentes funcionales con hooks, sin arrastrar un framework pesado encima.

Para frontends que piden una estructura más rígida y tipada de serie, habitual en aplicaciones de gestión con equipos grandes.

Desarrollo a medida sobre WordPress cuando el cliente necesita gestionar su propio contenido sin depender de nadie.

Para sitios de contenido como este. Cero JavaScript por defecto y contenido en Markdown sin montar un CMS.

Utility-first. Consistencia visual sin acumular una hoja de estilos que nadie se atreve a tocar.

Las bases de datos con las que he trabajado en producción. Bien modeladas e indexadas aguantan muchísimo más de lo que suele asumirse antes de necesitar nada exótico.

Caché, sesiones y datos de acceso muy frecuente. En un motor de disponibilidad es la diferencia entre responder al instante y volver a preguntar lo mismo a la base de datos.

El esquema es la decisión más cara de revertir de un sistema. Merece más tiempo del que normalmente se le dedica.

Leer planes de ejecución, entender qué índice se está usando y por qué. En sistemas con carga real es donde aparecen las mejoras grandes.

Separar lecturas de escrituras cuando el volumen de consulta supera con mucho al de escritura, que es lo habitual en motores de disponibilidad.

El proveedor cloud con el que trabajo. EC2, RDS y S3 cubren la mayor parte de lo que un backend necesita sin añadir servicios por moda.

Entornos reproducibles. Compose para desarrollo local con paridad razonable respecto a producción.

Infraestructura declarada en código. El valor real no es automatizar el alta, es poder leer en un repositorio qué hay levantado y por qué.

Reverse proxy, terminación TLS y cabeceras de seguridad. La pieza que casi nunca da problemas y por eso se olvida.

El sistema donde acaba corriendo todo. Saber leer logs, procesos y consumo de recursos ahorra muchísimo tiempo de diagnóstico.

Para absorber picos de carga sin sobredimensionar la infraestructura el resto del tiempo.

Integración y despliegue continuos. Si desplegar da miedo, se despliega poco; y si se despliega poco, cada despliegue es más arriesgado.

Diseño de APIs pensando en quien las va a consumir, no en cómo está organizada la base de datos por dentro.

Un adaptador por proveedor, un modelo único hacia dentro. Toda la rareza de cada tercero contenida en un solo sitio.

Sin ceremonia: lo que importa son las fronteras y la dirección de las dependencias, no reproducir un diagrama.

Medir antes de optimizar, y priorizar dejar de hacer trabajo por encima de hacerlo más rápido.

IDEs de JetBrains para PHP y Java. El refactor automático y la navegación de código compensan de sobra en bases grandes.

Para frontend, TypeScript, Terraform y Markdown.

Control de versiones, pull requests con revisión y protección de la rama principal.