How I do frontend the backend way

The trend is to solve everything on the frontend and AI only encourages it. But the backend and PHP are not dead. In this article based on my talk, I sum up the risks of frontend-heavy applications and the advantages of the backend approach with Symfony.

Even before AI arrived, there was a clear trend among programmers to solve practically everything on the frontend. With the rise of artificial intelligence, this tendency has only grown stronger – if you ask AI for advice today, it will very often automatically suggest a frontend technology, even where a classic backend solution would make much more sense.

Yet the backend and technologies like PHP are far from dead, and in many situations they are still the best choice. And if you are working on an existing project, it makes even less sense to rewrite the application into whatever programming language and framework happens to be in fashion. That is why I want to use this article as a reminder that developing applications mainly with backend technologies still makes sense.

A typical application and what we expect from it

Imagine a typical application that addresses a real user need – for example, the digital control of a complex manufacturing process. Such an application has to cover lots of edge cases, keep its data consistently stored and well linked, and at the same time be user-friendly, whether it is used by the managing director or a worker on the shop floor.

Thanks to AI, more and more applications are being built that are "frontend, frontend, frontend", as if the backend had practically ceased to exist. In my own work, however, I typically come across existing PHP applications that are not built on the latest technologies – and I have no reason to forcibly rewrite them into a different stack. In the end, it would be inefficient in terms of both time and money. And if you have a very old PHP application that you no longer want to develop further, even an old PHP application can be kept running. I describe how in the article How to operate old PHP applications. Of course, if you want to keep developing the application, you need to find a budget for an upgrade or even a gradual rewrite.

When does it make sense to choose frontend technologies?

Frontend technologies certainly have their place and in many cases they are essential. Typically these are situations where:

• the application requires a high level of interactivity
• it needs to communicate with one or even several APIs (you can find out how to design and implement such an API in the article REST API Platform)
• the backend is handled by a completely different service and there is no classic database
• you want to save costs by sharing parts of the code between the frontend and the backend
• you want to build multiple clients on top of an existing API. For example, a web, mobile and desktop application
• you need dynamic calculations that do not require any communication with the backend at all

Risks of frontend-based applications

Moving logic to the frontend brings a number of risks that I encounter again and again in practice. All of them can be solved, but it is better to prevent them so that the programmer does not even have to think about the possibility of such a problem arising and therefore having to deal with it.

Leaking know-how

If the business logic – for example, a specific price calculation – is located in the frontend, anyone with a little experience in reading code can inspect it in the browser and uncover the company's sensitive know-how.

Unnecessarily many requests

I came across an e-shop where each item was loaded by a separate JavaScript request. I was interested in several items, so I opened them in ten windows – and so many requests were generated. The server then blocked me. As a customer, I was left with an unavailable e-shop.

Unprotected APIs

It sounds comical, but it happens quite often that API endpoints are not protected by a login, a token or any other means. I have personally encountered this! For example, during one performance optimization it turned out that the data at the API URLs was freely accessible without logging in, serving all the data. Yes, the frontend only displays part of it, but much more is sent to the browser – for example, an entire database of users with personal data, which nobody should be able to access without logging in and having the proper permissions. And that is exactly why frontend technologies require much greater emphasis on web security.

Technology fragmentation

There is a huge number of frontend frameworks and they change often. With every new project, a programmer has to learn a new framework – and the question is whether it is worth investing the time. Personally, my favourite frontend technology is SvelteJS. And it always holds true that fewer technologies are better.

AI-generated code

Today AI generates an enormous amount of code whose security quality is questionable, to say the least. But someone has to maintain that code. The less code there is, and the more secure it is by default, the better.

The backend approach: PHP and Symfony

I do not rewrite the PHP applications that come my way – I learn the technology that is already there and build on it. I do not need to be "modern" at all costs; I want to be flexible and have as little code in the project as possible, because in my view that is a sign of a better project.

I often work with the PHP framework Symfony or with Nette. PHP has moved forward significantly in recent years and today I consider it a good programming language with a great ecosystem, such as PHPStan, PHPUnit and quality libraries. New applications are built according to modern standards, so it is easy to find your way around them. And older projects can be migrated to newer PHP versions with the Rector tool, see upgrading PHP with Rector or by using AI and vibecoding.

When I handle as much logic as possible on the backend, I do not have to deal with a separate API and all the problems that come with an API – including authentication, authorization and security. Less work by default means more security. I handle everything directly in the relevant part of the application.

Specific advantages of the backend approach

Forms, validation and HTML5 attributes

Symfony automatically generates HTML5 attributes for forms, which improve the user experience, and it offers validation that can be configured to take information directly from the definition of the entities stored in the database. If you use Doctrine, a single line is enough and, for example, the string length defined on the entity is automatically carried over into the form validation – with minimal work for the programmer.

Validation takes place the standard way on the backend. You write one class describing what the form should look like, and the framework checks lots of things by itself – for example, that the user only chooses from an allowed set of values. This automatically prevents an attacker from sending nonsense into your application. It simply works out of the box without the programmer having to write any validation code. At the same time, when I am trying out a prototype, working with a standard form is much easier for me than testing an API.

Working even without JavaScript

An application built this way can work to a large extent even without JavaScript. From the user's point of view this does not make much sense today, but from the point of view of development and testing it is more convenient – you do not have to deal with lots of API calls and search the console for what each script is doing. It is also better for SEO.

Optimization and caching

The backend approach allows you to optimize at a lower level. For example, directly at the level of SQL queries, which is often not possible when calling a separate API, or you have to write your own endpoints. On the backend you can also nicely cache what all users use together, and the database itself caches some things too. Whatever is cached thanks to one user is then available faster to other users. You can read more about speeding up websites in the article How to speed up the web, and about the differences between databases in the article SQL: PostgreSQL, MySQL, MariaDB.

One request instead of dozens

To display data to users I use the framework's standard templates, so I do not have to learn anything new. I can render the same template directly into the page or load it with JavaScript – on the frontend, one request (classic AJAX) is then enough to return the entire new content, without any unnecessary extra data. This is usually faster than loading data with lots of requests and assembling it in the browser, which then often slows down considerably. On top of that, the template is truly separated from the application logic.

Reusability and code quality

When you write the logic and functions on the backend, you have one piece of code that can easily be reused, instead of writing the same thing separately for the frontend and the backend. On top of that code you can also use PHPStan with strict types or PHPUnit, which increases the chance that it will be of good quality. You program more or less in one language – a bit of JavaScript is of course needed, but only for loading and the most essential dynamic elements.

Easier testing

Testing forms and logic on the backend is often easier than fiddling with an API. If you send a fragment of an HTML page, you get the response from the URL exactly as the user will see it (just without styles), and you do not have to click through anything complicated. Values that are calculated and stored in the database can be covered by automated tests as well as static analysis.

New features with framework updates

If you use a framework, new features arrive automatically when you upgrade it. Without improving the application myself, it improves itself to a certain extent.

A practical demonstration

You can also watch a real demonstration of such an application and this topic as a recording of my talk at a meetup of the Phpkáři community (in Czech):

At first glance it looks like any other web application that loads data and shows the user lots of information calculated according to the current situation. It uses a classic Symfony form – after submission, the data is processed on the backend, validated and saved. The backend generates the entire dynamic part and the frontend merely displays it.

When I turn off JavaScript in the browser, an application built in React, for example, would show just a blank page. Here some data does not load, but the form remains functional – the data can be saved as usual. And when I open the URL of the dynamically loaded part directly, I can see (albeit without styles) exactly what the backend is sending, which is a much easier check for a developer than debugging an API.

A similar approach can also be combined with a frontend framework – for example, SvelteJS adds interactivity while all the logic and forms stay on the backend.

AI and a robust backend

In the age of AI, I think it is all the more important to pay attention to the quality of the backend. From the point of view of both performance and security, the backend is essential. It is the backend that takes care of data, permissions and business logic. A poorly built backend can mean a bad or even dangerous application, regardless of how nice the frontend looks.

Conversely, when you have a robust backend application where everything is neatly connected and validated by the framework, deploying AI is much safer too. AI can generate quality code that needs only minimal fine-tuning, and thanks to the existing structure of the framework, no duplicate code is created. The more robust the application, the more willing I am to let AI into it. I write more about programming with the help of AI in the article Vibecoding – programming with AI.

Looking ahead: Live Components

If I wanted to build a purely frontend application in the future, I would look for a technology where I write the code once and it is exported or generated so that, for example, validation works identically on the backend and the frontend, without duplication.

Similar tools already exist today – worth mentioning are Laravel Livewire and Symfony UX Live Components. These are backend projects in which you define what forms and their validation should look like. Validation takes place on the backend, but it works interactively – the frontend sends data, the backend validates it and sends a response back. For the user, the result is fully interactive, while all the logic stays on the backend and the developer comes into contact with pure frontend technology only minimally. For some simpler validations, frontend code is generated as well, and validation takes place directly in the browser without sending data to the backend.

Summary

Frontend technologies have their irreplaceable place, but not every problem needs to be (or should be) solved on the frontend. The backend approach, if you learn for example PHP and the Symfony framework, brings less code, fewer security risks by default, easier testing, better reusability and more efficient caching. Moreover, with existing PHP projects it makes no sense to rewrite everything into a modern frontend stack just because it is the current trend. And in the age of AI, it is doubly true that a quality backend is the foundation.

If you are interested in what a programmer's work involves, read the article What is a programmer's job. And if you would like to learn similar practices hands-on or need help with your application, take a look at the web application development training or contact me.