Why you should keep your frontend and backend separate

Web applications are essential for today’s businesses of any size. The pandemic years have accelerated our dependency on web presence and digital products more than ever. Businesses in their simplest forms rely on web technologies to schedule appointments, make online orders, and communicate with clients. In more complex scenarios, businesses are moving towards integrating digital products in their processes to increase efficiency and improve automation, real-time monitoring and reporting.

However, little is known to some of the non technical business owners and decision makers on the architecture that is behind their web presence. This becomes especially relevant with custom built web functionalities that are not always available with website builders, Wordpress, and Shopify storefronts. One important aspect of this architecture where a decision needs to be made is whether to separate the frontend and the backend of a web application and what are the cons and pros of this approach. This point will be the focus of this article.

So what is the backend and the frontend ?

Let us start with the frontend, which we are all familiar with. A frontend is simply what the visitor of a website or a web application sees and interacts with. This includes all text, images, menus, buttons, and forms that appear on the website. The content of the website can be static, which means components that typically do not change such as the logo, menus, and anything that appears to be there all the time, and dynamic content, examples of which can be a username in the corner of the page or health records of a patient appearing on a doctor’s screen.

Any content that is dependent on the user who is currently logged in or on a specific identifier (such as a product id) or a combination of identifiers falls into this category as well. Dynamic content is generated by some business logic that processes the user’s request and decides on what to display the screen. This takes us to the backend.

The backend is the core of the web application where a lot of the processing, filtering, querying, and managing database records takes place. This is where the user’s request is received (such as clicking on the login button) and next actions are determined, and the data is retrieved and returned to the front end (such as data pertaining to a user after a successful login). The backend is typically much more resource consuming as it performs large computations, accesses the database and performs input/output operations on a storage.

Design Considerations

In the early days of web development, Model-View-Controller design pattern emerged as a popular way of writing web applications and designing frameworks. The pattern emphasized the need to keep the three components of web applications separate; the Data component (Model), the Business Logic (Controller) and the User Interface (View). Frameworks such as Ruby on Rails, .Net, and others were built with this design pattern as their foundation. But while the separation of these components in code was achieved, they were all initially still hosted together as part of one. Controllers had to recompute the rendering of the whole page with every user interaction, and execution was expensive and the experience slow.

Then came Ajax (Asynchronous JavaScript and XML) in 2005. With Ajax, web applications sent and retrieved data from a server asynchronously (in the background) without interfering with the display and behavior of the existing page. Thus, by decoupling the data layer from the presentation layer, Ajax allowed web pages and, by extension, web applications, to change content dynamically without the need to reload the entire page . This gave JavaScript a massive boost in its importance and use.

Since then, web development, asynchronous computing and javascript frameworks have evolved greatly, and they grew in their powers and complexities. Angular, React, and Vue are some of the most popular frontend frameworks today, and they are all based on JavaScript. In fact, these frameworks also follow the MVC design pattern, but they do so in the context of the presentation layer (the user’s interface) and can live as standalone hosted services.

Today, it is not uncommon to find web applications of any size and complexity hosting their frontend and backend services separately. Moreover, it is often the case that the codebase for these layers, as well as their integration and deployment pipelines are entirely separate.

Naturally, there is a debate on whether this separation is desirable or introduces additional and unnecessary levels of complexities. Let us look at some of the arguments presented by those who are opposed to the idea of splitting the frontend and the backend from each other, and what the counter arguments are.

1. Deployment synchronization between the front end and the backend:

What happens if your frontend is ready with a new feature to be released but the backend is not ? Opponents of separating the frontend from the backend argue that the biggest issue in such architecture is that frontend code and the backend code is deployed separately. It means the frontend and the backend teams need to spend a lot of time coordinating when to deploy and how to deploy.

While this is certainly a point to take into consideration, our argument is that the problem is going to manifest itself in some form regardless of whether you have a separate frontend and backend or not. Creating a new feature or fixing a bug may well need changes on both ends. However, while keeping everything together certainly eliminates the synchronization element of deployment, it takes away lots of flexibility for teams and development efficiency. Today’s agile development approach and the ease of CI/CD integration should make this problem easier to anticipate and manage. This is why a lot of organizations opt-in for this approach.

2. Similar context, syntax and objects

When developing any application, software developers organize data by types. They do so by creating “Classes” and instantiating objects out of them. For example, a person can be a Class with some known characteristics: height, weight, and hairstyle. Opponents of separating the frontend from the backend argue that if you create this type of class on the backend, you’d have to create a similar class on the front end, which means duplicating code. We personally find that this argument is brought up more often in cases where the backed is developed using a strongly typed language such as C# or Java.

While true, replicating a class that is used by the backend on the frontend might not actually be a bad thing. The backend and the frontend grow to become separate projects by themselves with their own data structures. And even if the majority of classes are similar and need to be duplicated, the few classes that need to be different are the ones that will give everyone major headaches had the backend and the frontend been kept together for this reason.

Shared data structures become dependencies. Software engineers know how much pain these will cause during development and how many of them will be sources of bugs. Additionally creating a data structure on the front end, especially with modern frontend frameworks, is straightforward and takes minimal effort. Data abstraction is extremely easy to achieve with “Typescript” - a superset of Javascript - that this concern is no longer justified.

3. Security:

Obviously, security considerations are paramount when it comes to web applications and data stored on the cloud. There are arguments that hosting the frontend and the backend together removes the need to expose an API to the outside world and keeps the application more secure.

APIs or Application Programming Interfaces are means of software programs to communicate with each other by defining a certain contract of communication. In the case of web applications and web, the API is the backend that is running on the server which receives requests from client programs over http and sends back responses. The clients know how to interact with the backend because they know what the contract is; the endpoints exposed by the backend for clients to call and expect a certain response. For example, a call to www.mysite.com/products will probably return a list of products, and so on.

Back to the earlier argument of security. When the backend and the front are hosted on the same server, then sure, the backend is not exposed to the outside world (well, kind of ..). It still does not mean that a web application is secure: there are still many other areas where web applications can be vulnerable to Cross Site Scripting (XSS) attacks, SQL injection attacks, among many others.

Up to now, we’ve mentioned some of the major areas where proponents of joining the front end and the backend argue the most, and we have presented some of our counter-arguments too. But we have not yet mentioned the most important advantage of splitting the frontend and the backend: expandability.

Had all web applications chosen not to create a separate backend exposing an API, then we would not have weather apps on our phones, and the web would have been a set of disconnected nodes. An API, if well designed and well secured, could open up a world of possibilities for the business. Not only can you rip off a whole frontend and replace it with another (even built with a different framework) without making changes to your business and data logic, but you could also have mobile apps, PWAs, and many other client pieces of software and hardware interacting with your API. You could expand your audience and be present on many devices. You could break down your complex systems into a set of smaller, more efficient, and more manageable micro-services, and much more.

Conclusion

The tech world is moving away from the traditional model of developing, deploying and maintaining web applications, partly because it stopped being useful for businesses and expensive to maintain. Modern web applications are built with expandability and scalability concepts in mind from an early stage.

Modern project management principles and agile approach in software development have made it easier for teams to communicate and stay informed of the work of others, to the point that it is hardly a reason to argue that maintaining separate frontend and backend complicates this. Similarly, for the reasons mentioned above, one cannot argue that maintaining separate data types on the frontend and the backend is a reason to not adopt this approach.

Security will remain a concern as long as we have the web. But the concern that exposing an API will make a web application vulnerable is not the whole truth. In the end, technology exists to facilitate our processes and help us with our businesses and with our lives. It should be driven by what is good for us. For the time-being, we see that maintaining a separate backend and a separate frontend keep development effort efficient, less expensive and more manageable. It is more scalable in the long run and is more beneficial from a business perspective.