Unless your web application is 100% client-side code, you should split it into a backend API and a frontend client. Too often people fall into the trap of believing that because they need a “quick” turnaround they shouldn’t spend the time developing a separate API and client-side app, or they believe that their application is small enough that they can get by without doing this.

This usually results in what I’ll call an all-in-one application. In this breed of application, your business logic and user interface are one entity running on a server. However, making your web application have a separate frontend and backend has many great benefits.

1. Modularity

One benefit of splitting your app up into a separate backend and frontend app is modularity. With your application logic completely separated from your user interface, you have a slightly more modular web application. Modularity aids in a number of things, including testing, readability, and maintainability.

2. Reusability

With a separate API, your application logic can be reused by any number of applications. This means you can make a mobile application that utilizes your API, consume your API in a completely separate application, or even allow others to access your API (for free or for a price).

3. Content Delivery

With your client-side application  a completely separate entity, you can take care of advanced static file serving techniques that are otherwise unavailable to you in applications where the UI needs to be rendered server-side. For example, you can now use NGINX and some simple rules to cache your entire client-side application.

4. Responsiveness

One of the greatest pitfalls with an “all-in-one” server-side application is giving users responsive feedback. A typical workflow for a user clicking a button to fetch data looks like this in a server-side application:

  1. A user clicks a button to fetch data
  2. The browser sends a request to the server
  3. The server queries the database
  4. The application performs logic on the data
  5. The application renders data in a view
  6. The server returns the response to the user
  7. The user sees feedback after waiting the whole time for the page to load.

With a separate client-side application, you can take advantage of a number of feedback mechanisms such as using loading spinners or progress bars. Once your request comes back (via an AJAX call, for example), you can update your view.

Edit 1

5. Versioning

Yes, I added a #5. With separate API and UI projects, you can upgrade and deploy one without the other. If there’s a critical issue in your new UI deploy, you can roll it back without sacrificing the performance improvements you just made in the API project.

Edit 2

What Are The Advantages of a Monolithic Architecture?

This split architecture has many excellent benefits. However, there are some benefits to using a Monolithic Architecture as well. For instance, if your application is contained to a single project, you can develop it much faster. It’s no secret that more coding is involved to make a separate user interface and API (but many frameworks are making this easier). There are also security benefits that you get out of the box. For instance, the fact the you’re not exposing an API at all. There are ways to protect your API, but not having to is even better. If you have more advantages you’d like to talk about leave a comment and let’s talk about it.


I know to many software developers this may seem like an obvious choice. Yet, so many people still decide to ignore this simple architectural choice due to either unfamiliarity with the concept, or simple laziness. There are some valid use-cases for a monolithic architecture. However, I see far more valid use-cases for the split API and UI. Even if that API is consumed by a server-side application. I urge any developers who have yet to try this concept to do so. I think you’ll find the result to be a much cleaner solution than the alternative.

Comment below if you have questions on how to achieve this in your web application, and please share this post if it was helpful to you.

Recommended Posts


  1. Using absolutes like this post does is a trigger for me to look upon the developer with skepticism. I fully understand the intent but it’s often post like these that may breed poor information across our industry or a sense of elitism. I do appreciate the effort put into it and that you are trying to better all of us by sharing your thoughts. In general, I agree with your points.

    However, to make this more educational/thought leading and less doctrinaire, I challenge you to present the alternative points of view instead of simply relegating to this sentence: “Yet, so many people still decide to ignore this simple architectural choice due to either unfamiliarity with the concept, or simple laziness.”

    Looking forward to the next post.

    • Thank you for the feedback Justin. I’ll work on some use-cases and reasons you may not always want this architecture. I do want to try and be as educational as possible.

  2. For one, you don’t want to do this if you care about the loading speed of your webapp or care very deeply about SEO. Also, it need not be a binary option. I have always favored the hybrid approach, turning a certain aspect of the app into an API (i.e dashboard) while leaving some parts server rendered.

    I also detect a serious attempt at elitism with this post. It’s not at all necessary, but unfortunately all too common in the field of software today it seems. Learn to disagree without insulting others view points. You don’t know everything.

    Every method is a trade off.
    People pick the methods with the best merits that make sense to them and their projects. It’s really that simple.

    • Hi, I’m not trying to sound elitist, but I am trying to promote what I think is a good architecture. I’m happy to discuss the topic. And due to popular demand I have added a section I’ll be compiling the benefits of a Monolithic application into.

      Can you elaborate on why you think you get better loading speed out this kind of architecture? In my experience, when querying large sets of data I am typically stuck staring at a blank browser window for a while with applications built this way. I prefer having the freedom to lazy-load this data on the client-side, allowing the user to view a subset of it while the rest continues to load. I think it makes for a better UX.

      Also, and I’m less knowledgeable on this, how can having a monolithic application positively influence SEO?

      • Because monolithic applications render the data without additioal javascript, the contents can be indexed by searchengine bots. If it is rendered by javascript, most bots will not be able to execute it and see the result. Hence Iyoko’s comment that there is a big impact regarding SEO.

        • That’s an excellent argument for server-side rendering. However, that doesn’t mean your application has to be a monolithic one. You can still develop your UI separate, and take advantage of server-side rendering. You could develop a PHP UI, in which case those benefits would come out-of-the-box, or you could use something “fancy” like server-rendered JavaScript.

  3. I like your train of thought in this article. The reason, the UI and the server-side code can be developed independently. Simply define the post/get responses between the two. It gives the teams complete separation and they can work on their components asynchronously. As long as responses are kept up to date. Keeps UI developers completely away from having to compile server side crap. Ditto for the server-side dev team. A clean separation really does promote the modularity you are writing about. Either part can be easily replaced by a completely new architecture. It also makes it easier to debug.

Add a Comment

Your email address will not be published. Required fields are marked *