Cómo hago frontend desde el backend

La tendencia es resolverlo todo en el frontend y la IA no hace más que reforzarla. Pero el backend y PHP no están muertos. En este artículo basado en mi charla resumo los riesgos de las aplicaciones centradas en el frontend y las ventajas del enfoque de backend con Symfony.

Ya antes de la llegada de la IA existía entre los programadores una clara tendencia a resolver prácticamente todo en el frontend. Con el auge de la inteligencia artificial, esta inclinación no ha hecho más que acentuarse: si hoy le pide consejo a una IA, muy a menudo le ofrecerá automáticamente una tecnología de frontend, incluso allí donde una solución clásica de backend tendría mucho más sentido.

Sin embargo, el backend y tecnologías como PHP están lejos de estar muertos y en muchas situaciones siguen siendo la mejor opción. Y si trabaja en un proyecto existente, tiene todavía menos sentido reescribir la aplicación al lenguaje de programación y al framework que estén de moda en ese momento. Por eso quiero recordar con este artículo que desarrollar aplicaciones con tecnologías principalmente de backend sigue teniendo sentido.

Una aplicación típica y qué esperamos de ella

Imaginemos una aplicación típica que resuelve una necesidad real del usuario, por ejemplo, el control digital de un proceso de producción complejo. Una aplicación así tiene que cubrir muchos casos límite, tener los datos almacenados de forma coherente y bien relacionados y, al mismo tiempo, ser fácil de usar, ya la utilice el director o un operario de la planta.

Gracias a la IA, hoy surgen cada vez más aplicaciones que son «frontend, frontend, frontend», como si el backend prácticamente hubiera dejado de existir. Sin embargo, en mi trabajo me encuentro habitualmente con aplicaciones PHP existentes que no están construidas sobre las tecnologías más recientes, y no tengo ningún motivo para reescribirlas a la fuerza en otro stack. Al final, sería ineficiente tanto en tiempo como en dinero. Y si tiene una aplicación PHP muy antigua que ya no quiere seguir desarrollando, incluso una aplicación PHP antigua se puede seguir operando. Cómo hacerlo lo describo en el artículo Cómo operar aplicaciones PHP antiguas. Por supuesto, si quiere seguir desarrollando la aplicación, es necesario encontrar presupuesto para una actualización o incluso para una reescritura gradual.

¿Cuándo tiene sentido elegir tecnologías de frontend?

Las tecnologías de frontend tienen, por supuesto, su lugar y en muchos casos son imprescindibles. Normalmente se trata de situaciones en las que:

• la aplicación requiere un alto grado de interactividad
• es necesario comunicarse con una o incluso varias API (cómo diseñar e implementar una API así lo encontrará en el artículo REST API Platform)
• el backend lo resuelve un servicio completamente distinto y no hay una base de datos clásica
• quiere ahorrar compartiendo partes del código entre el frontend y el backend
• quiere construir varios clientes sobre una API existente. Por ejemplo, una aplicación web, móvil y de escritorio
• necesita cálculos dinámicos para los que no hace falta ninguna comunicación con el backend

Riesgos de las aplicaciones realizadas en el frontend

Trasladar la lógica al frontend conlleva una serie de riesgos con los que me encuentro una y otra vez en la práctica. Todos tienen solución, pero es mejor prevenirlos para que el programador ni siquiera tenga que pensar en que puede surgir un problema así y, por tanto, en que tiene que resolverlo.

Fuga de know-how

Si la lógica de negocio, por ejemplo un cálculo específico del precio, está ubicada en el frontend, cualquiera con un poco de experiencia leyendo código puede examinarla en el navegador y descubrir así el know-how sensible de la empresa.

Demasiadas peticiones innecesarias

Me encontré con una tienda online en la que cada producto se cargaba mediante una petición JavaScript independiente. Me interesaban varios productos, así que los abrí en diez ventanas, y se generaron tantas peticiones. A continuación, el servidor me bloqueó. Como cliente, me quedé con la tienda online inaccesible.

API sin protección

Parece cómico, pero ocurre con bastante frecuencia que los endpoints de la API no están protegidos mediante inicio de sesión, token ni de ninguna otra forma. ¡Me lo he encontrado personalmente! Por ejemplo, durante una optimización del rendimiento resultó que los datos en las URL de la API eran accesibles libremente sin iniciar sesión y se servían todos los datos. Sí, el frontend solo muestra una parte, pero al navegador se envía mucho más, por ejemplo, toda una base de datos de usuarios con datos personales a los que nadie debería poder acceder sin iniciar sesión y sin los permisos adecuados. Y precisamente por eso, con las tecnologías de frontend hay que poner mucho más énfasis en la seguridad web.

Fragmentación de tecnologías

Existe una enorme cantidad de frameworks de frontend y cambian a menudo. Con cada nuevo proyecto, el programador tiene que aprender un nuevo framework, y la pregunta es si merece la pena invertir ese tiempo. Personalmente, mi tecnología de frontend favorita es SvelteJS. Y siempre se cumple que cuantas menos tecnologías, mejor.

Código generado por IA

Hoy la IA genera una enorme cantidad de código cuya calidad en materia de seguridad es, como mínimo, discutible. Pero alguien tiene que mantener ese código. Cuanto menos código haya y cuanto más seguro sea por defecto, mejor.

El enfoque de backend: PHP y Symfony

Las aplicaciones PHP que llegan a mis manos no las reescribo: aprendo la tecnología que ya utilizan y construyo sobre ella. No necesito ser «moderno» a toda costa; quiero ser flexible y tener el menor código posible en el proyecto, porque para mí eso es señal de un proyecto mejor.

A menudo trabajo con el framework PHP Symfony o con Nette. PHP ha avanzado notablemente en los últimos años y hoy, en mi opinión, es un buen lenguaje de programación con un ecosistema excelente, como por ejemplo PHPStan, PHPUnit y bibliotecas de calidad. Las nuevas aplicaciones se crean según estándares modernos, por lo que es fácil orientarse en ellas. Y los proyectos más antiguos se pueden migrar a versiones más recientes de PHP con la herramienta Rector, véase actualización de PHP con Rector, o utilizando IA y vibecoding.

Cuando resuelvo la mayor parte posible de la lógica en el backend, no tengo que ocuparme de una API independiente ni de todos los problemas relacionados con ella, incluidas la autenticación, la autorización y la seguridad. Menos trabajo por defecto significa más seguridad. Lo resuelvo todo directamente en la parte correspondiente de la aplicación.

Ventajas concretas del enfoque de backend

Formularios, validación y atributos HTML5

Symfony genera automáticamente en los formularios atributos HTML5 que mejoran la experiencia del usuario y ofrece validaciones que se pueden configurar para que tomen la información directamente de la definición de las entidades almacenadas en la base de datos. Si utiliza Doctrine, basta con una sola línea y, por ejemplo, la longitud de la cadena definida en la entidad se traslada automáticamente a la validación del formulario, con un trabajo mínimo para el programador.

La validación se realiza por la vía estándar en el backend. Escribe una clase que describe cómo debe ser el formulario y el framework comprueba por sí mismo muchas cosas, por ejemplo, también que el usuario elija solo entre un conjunto de valores permitidos. Así evita automáticamente que un atacante envíe disparates a su aplicación. Simplemente funciona out of the box sin que el programador tenga que escribir código de validación. Al mismo tiempo, cuando pruebo algún prototipo, me resulta mucho más cómodo trabajar con un formulario estándar que probar una API.

Funcionamiento incluso sin JavaScript

Una aplicación construida de esta manera puede funcionar en gran medida incluso sin JavaScript. Desde el punto de vista del usuario esto hoy no tiene mucho sentido, pero desde el punto de vista del desarrollo y las pruebas es más cómodo: no tiene que lidiar con muchas llamadas a la API ni buscar en la consola qué hace cada script. Además, es mejor para el SEO.

Optimización y caché

El enfoque de backend permite optimizar a un nivel más bajo. Por ejemplo, directamente a nivel de las consultas SQL, algo que a menudo no es posible al llamar a una API independiente, o bien tiene que escribir sus propios endpoints. En el backend también puede almacenar cómodamente en caché lo que utilizan todos los usuarios en conjunto, y la propia base de datos también cachea algunas cosas. Lo que se guarda en la caché gracias a un usuario está disponible más rápido para los demás. Encontrará más sobre cómo acelerar sitios web en el artículo Cómo acelerar la web, y sobre las diferencias entre bases de datos en el artículo SQL: PostgreSQL, MySQL, MariaDB.

Una petición en lugar de decenas

Para mostrar datos al usuario utilizo las plantillas estándar del framework, así que no tengo que aprender nada nuevo. La misma plantilla puedo renderizarla directamente en la página o cargarla con JavaScript; en el frontend me basta entonces con una sola petición (AJAX clásico) que devuelve todo el contenido nuevo, sin datos innecesarios de más. Esto suele ser más rápido que cargar los datos con muchas peticiones y montarlos en el navegador, que a menudo se ralentiza bastante. Además, la plantilla está realmente separada de la lógica de la aplicación.

Reutilización y calidad del código

Cuando escribe la lógica y las funciones en el backend, tiene un único código que se puede reutilizar fácilmente, en lugar de escribir lo mismo por separado para el frontend y el backend. Sobre ese código puede además utilizar PHPStan con tipos estrictos o PHPUnit, lo que aumenta la probabilidad de que sea de calidad. Programa más o menos en un solo lenguaje; por supuesto, hace falta algo de JavaScript, pero solo para la carga y los elementos dinámicos imprescindibles.

Pruebas más sencillas

Probar formularios y lógica en el backend suele ser más sencillo que andar experimentando con una API. Si envía un fragmento de una página HTML, obtiene la respuesta de la URL tal y como la verá el usuario (solo que sin estilos) y no tiene que ir haciendo clic de forma complicada. Los valores que se calculan y se guardan en la base de datos puede cubrirlos con pruebas automatizadas y también con análisis estático.

Nuevas funciones al actualizar el framework

Si utiliza un framework, al actualizarlo llegan automáticamente nuevas funciones. Sin que yo mejore la aplicación, en cierta medida se mejora sola.

Una demostración práctica

Una demostración real de una aplicación así y este tema también puede verlos como grabación de mi charla en el meetup de la comunidad Phpkáři (en checo):

A primera vista parece una aplicación web como tantas otras, que carga datos y muestra al usuario mucha información calculada según la situación actual. Se utiliza un formulario clásico de Symfony: tras el envío, los datos se procesan en el backend, se validan y se guardan. Toda la parte dinámica la genera el backend y en el frontend solo se muestra.

Cuando desactivo JavaScript en el navegador, una aplicación construida, por ejemplo, en React mostraría solo una página en blanco. Aquí algunos datos no se cargan, pero el formulario sigue funcionando: los datos se pueden guardar con normalidad. Y cuando abro directamente la URL de la parte cargada dinámicamente, veo (aunque sin estilos) exactamente lo que envía el backend, lo que para un desarrollador es una comprobación mucho más sencilla que depurar una API.

Un enfoque similar también se puede combinar con un framework de frontend: por ejemplo, SvelteJS aporta la interactividad mientras toda la lógica y los formularios permanecen en el backend.

La IA y un backend robusto

En la era de la IA creo que hay que cuidar todavía más la calidad del backend. Desde el punto de vista tanto del rendimiento como de la seguridad, el backend es fundamental. Es precisamente el backend el que se ocupa de los datos, los permisos y la lógica de negocio. Un backend mal hecho puede significar una aplicación mala o incluso peligrosa, independientemente de lo bonito que sea el frontend.

Por el contrario, cuando tiene una aplicación de backend robusta, en la que todo está bien conectado y validado por el framework, también es mucho más seguro utilizar la IA. La IA es capaz de generar código de calidad que solo necesita un ajuste mínimo y, gracias a la estructura existente del framework, no se genera código duplicado. Cuanto más robusta es la aplicación, más dispuesto estoy a dejar entrar a la IA. Escribo más sobre programar con ayuda de la IA en el artículo Vibecoding: programación con IA.

Perspectivas de futuro: Live Components

Si en el futuro quisiera construir una aplicación puramente de frontend, buscaría una tecnología en la que escriba el código una sola vez y este se exporte o genere de forma que, por ejemplo, la validación funcione igual en el backend y en el frontend, sin duplicidades.

Herramientas similares ya existen hoy; merece la pena mencionar Laravel Livewire y Symfony UX Live Components. Se trata de proyectos de backend en los que define cómo deben ser los formularios y su validación. La validación se realiza en el backend, pero funciona de forma interactiva: el frontend envía los datos, el backend los valida y devuelve una respuesta. Para el usuario el resultado es totalmente interactivo, mientras toda la lógica permanece en el backend y el desarrollador apenas entra en contacto con tecnología puramente de frontend. Para algunas validaciones más sencillas se genera también código de frontend y la validación se realiza directamente en el navegador sin enviar datos al backend.

Resumen

Las tecnologías de frontend tienen su lugar insustituible, pero no todos los problemas tienen que (ni deben) resolverse en el frontend. El enfoque de backend, si aprende por ejemplo PHP y el framework Symfony, aporta menos código, menos riesgos de seguridad por defecto, pruebas más sencillas, mejor reutilización y una caché más eficiente. Además, en los proyectos PHP existentes no tiene sentido reescribirlo todo a un stack de frontend moderno solo porque sea la tendencia actual. Y en la era de la IA se cumple por partida doble que un backend de calidad es la base.

Si le interesa en qué consiste el trabajo de un programador, lea el artículo Cuál es el trabajo de un programador. Y si quiere aprender procedimientos similares de forma práctica o necesita ayuda con su aplicación, eche un vistazo a la formación en desarrollo de aplicaciones web o póngase en contacto conmigo.