It is common when working on a web application, comprised of a server-side Web API, running on a framework like ASP.NET or NestJS, and a client-side Single Page Application (SPA), running on a framework like Angular, to refer to the server-side as "the back-end" and to the client-side as "the front-end". I've been a culprit of this until recently.

In an email exchange with Robert Martin about the concept of "Screaming Architecture" found in his "Clean Architecture" book, he kindly warned me to "be careful with my definition of front end code". He pointed out to me that not all code that runs on the client is front-end code and not all code that runs on the server is back-end code.

What IS the front-end ?

You'll see many definitions floating around the web, depending on the specific computing model and domain, but this excerpt from Wikipedia's entry is the best general definition I could find :

"In software architecture, there may be many layers between the hardware and end user. The front is an abstraction, simplifying the underlying component by providing a user-friendly interface, while the back usually handles data storage and business logic."

If we distill this a little, we are left with a pretty simple and reasonable definition of the front-end and the back-end. The front-end is an abstraction layer that provides an interface to the end-user of the application, in other words GUI code. The back-end handles data storage and business logic.

In the context of a web application that runs on something like traditional MVC where "pages" are served to the client, describing the entire layer of code that deals with producing the HTML, CSS and JS as "the front-end" usually complies with our general definition.

We often consider the location of execution as defining an architectural boundary. We think that code that runs in the browser is necessarily GUI code.  That’s not quite true, however. Business code can run in the browser, and formatting code run on the server.

But a SPA is a different animal. Take a SPA built on top of Angular, for example. The whole thing is written in HTML, CSS and JS (TS actually but you get my point), and runs on the client. Because of that, and coming from a Pages / MVC background, it is very easy to view the whole thing as "the front-end". But is that really the case?

A SPA is so much more

Let's go back to our definition. Front-end == end user interface, back-end == data storage and business logic. Most Angular SPAs are much more than just end user interface. They often include complex state management, client-side data storage, application logic and at times even business logic. Given this, calling the entire SPA a front-end does not comply with our definition and is in fact quite misleading.

In his email, uncle Bob reminded me that "this can be hard to understand.  We often consider the location of execution as defining an architectural boundary.  We think that code that runs in the browser is necessarily GUI code.  That’s not quite true, however. Business code can run in the browser, and formatting code run on the server."

This is sometimes hard to see when you are working on a project or product where the team controls both the server side API and the client-side SPA. Think about it though, it is entirely possible to develop a complex client-side SPA, with application and business logic, that depends entirely on third-party web APIs. For a team working on such an app, the SPA is the entire app and most certainly not "just the front-end". It has both front-end AND back-end code.

But what's the big deal, they're just words, you may think to yourself. Without going into too much detail (check out this article if the topic interests you), words influence our mental models and our actions. Full-stack and back-end inclined developers often view the SPA component of the web application they work on as "just the front-end" and this influences their design decisions negatively.

They may not take the care they should to secure the client-side of the application, for instance. May not spend as much time as they should making sure that the code is written and organized cleanly. Naming conventions may be non-existent or very poorly thought out. The client-side SPA becomes a bit like a second-class citizen in the whole project which is a big mistake, given that it often contains application and business logic.

So what should I call you?

Mr. Martin ended his email with this thought: "Partitioning the code based on business and formatting is wiser than separating the code based on browser and server." This makes a lot of sense to me. I honestly haven't figured out the best way to do this across both client and server in a complex web app running on a diverse tech stack, but I'm working on it.

For the moment, I'll avoid calling the client-side code "the front-end" and keep doing my best to partition the GUI code from the logic.

The takeaway? Don't call your SPA "the front-end". How about just calling it "the SPA" or "the client-side app". If you can think of a better way to refer to it, let me know in the comments.

I'm working on a follow-up to this article that will describe an architectural model for web applications running a SPA client and a Web API server. Subscribe to my newsletter to be notified when it comes out.