Inicio / Arquitectura

Arquitectura de webs y apps

La arquitectura es cómo está construida la web o la app: qué pieza hace qué, qué datos se guardan, cómo se publica y qué se puede cambiar sin romper el resto. El objetivo es una base que otra persona pueda seguir.

La hago yo, David López Dayer. Llevo más de 15 años como ingeniero de software. He trabajado en producto con equipos como Emirates, Coniq y Service2Media, y tengo un producto propio, Growth Trainer. No invento un stack para tu proyecto antes de verlo. La tecnología se elige por lo que hay que mantener, no por lo que está de moda.

Qué entra

Una web estática, como esta, puede ser la decisión correcta cuando el contenido cambia poco y lo que importa es la velocidad y el control. Una app con cuentas, datos y lógica de negocio necesita otra base. Las dos pueden estar bien hechas. Elegir la compleja cuando no hace falta es una forma cara de parecer moderno.

Rendimiento sin teatro

Miro el peso de lo que se descarga, las fuentes, las imágenes y el JavaScript que no aporta. En esta web las fuentes van servidas desde el propio dominio, la foto está en WebP con el JPEG de reserva, y los archivos estáticos se pueden cachear durante un año porque la HTML pide una versión concreta. Eso es higiene. No es una puntuación que vaya a prometerte.

No publico aquí un número de Core Web Vitals como si fuera un resultado de cliente. Esos datos salen del uso real, y cada proyecto los tiene distintos. Si en el tuyo hay un problema de carga, se mide y se corrige la causa, no se añade una herramienta más.

Seguridad de una web pública

En una web de contenidos, la seguridad práctica es concreta: cabeceras que impiden que otra página te incruste, una política de contenido que no carga scripts de terceros, y un formulario que no guarda datos en el servidor porque abre tu propio correo. Si tu producto tiene cuentas, pagos o datos de otras personas, el alcance es otro y se habla antes de escribir código.

Para quién es

Para quien tiene una web o una app que ya no se puede cambiar con calma, o para quien va a construir y quiere evitar esa situación. También para un equipo que tiene diseño y mensaje, y necesita a alguien que lo deje construido sin montar una plataforma de más.

Si el problema es solo de textos y de estructura de contenidos, puede que no haga falta tocar la arquitectura. La primera lectura sirve para no abrir un proyecto de ingeniería cuando el arreglo es otro.

Decisiones que quedan por escrito

Cuando hay que construir, dejo por escrito pocas decisiones y la razón de cada una. Dónde vive el contenido. Qué se calcula en el servidor y qué en el navegador. Cómo se publica un cambio y cómo se vuelve atrás. Qué datos son personales y cuáles no hace falta guardar.

Eso evita el proyecto que solo entiende quien lo escribió. También evita repetir la misma conversación cada vez que hay que cambiar un título o un flujo. Si la web es estática, la decisión puede ser así de simple: el HTML es la fuente, no hay base de datos, y un cambio se publica con el despliegue.

Si ya tienes un equipo, me adapto a su forma de publicar. No impongo un flujo nuevo cuando el que hay funciona. El trabajo es dejar el cambio dentro de ese flujo, con una explicación que otra persona pueda leer en diez minutos.

Cómo trabajo

Veo lo que hay, separo lo que se puede cambiar de lo que hay que rehacer, y lo escribo en un orden. La primera lectura no tiene coste y sale en unos días. Un cambio sobre algo que ya existe suele ir por semanas. Una base nueva se acuerda al ver el alcance. No hay tarifa pública: una revisión no es el mismo encargo que una app.

El diseño de la interfaz, cuando entra en el mismo trabajo, está descrito en diseño de webs y apps. El criterio es el mismo: del mensaje al código, sin pasarte a tres proveedores para una sola decisión.

Qué no hago

No mantengo un producto a ciegas ni entro en un sistema sin ver el código y el despliegue. No añado un framework, un gestor de contenidos o una capa de analítica porque sí. Si tu caso necesita un equipo más grande que una persona, te lo digo.

Escríbeme desde el contacto o a hello@dayer.es. Con la URL, o con el repositorio si puedes compartirlo, te digo por dónde empezaría.