Decoupling the front end from back end from a monolithic system

Published on: 26th Sep 2017

Updated on: 10th Jul 2025

Overview

We used to develop the entire system using ASP.Net web form or MVC. It sounds logical to build everything with the back end coding except for some validation processes using JavaScript which runs in the client browser.

The problem with this approach is that it's very hard to shorten the development time because the code file sharing is the big headache when the team gets bigger. Parallel development requires massive collaboration. Another biggest headache is if the customer wants to replace the back end code in C# with golang or Node.js, it is going to be very challenging because the front end code and back end code were mixed together.

For example, you want to develop an Online Shopping cart which has the catalog for public access. If you are using ASP.Net web form to develop the system, then the front end and the back end will be either in one file (ASPX) or two files (ASPX + ASPX.CS). If you are using MVC, you will have more "moving" components such as the model, view and controller. It's even harder to to sync the source codes among the development team members.

What we have done differently

We decoupled the front end from the back:

• The front end will be build with HTML, CSS + JavaScript.
• The back end will be developed in Generic Handler (ASHX) in ASP.Net/C# or whatever programming language in your mind. This ASHX provides an interface (API) for the client to submit their request, process by the web server and then response back to the client.

The benefits with this approach

For the front end developer,

• They will have the freedom changing the CSS styles without affecting the back end coding. Rearranging the layout without have to get permission from the back end programmer. Adding more UI effect with ease and they can be 100% sure that it won't affect the back end coding.
• All front end HTML, CSS, Javascript, images, etc can be cached by the web server or cache server. As a result, the live website runs blazingly fast.
• Easier to develop a new front end for a new target device such as kiosk machine.
• Easier to add new feature without affecting the back end.

For the back end developer,

• They focus on processing the incoming request and response with the appropriate data in JSON format.
• Any changes and optimization in the back end will not affect the front end.
• Easier to configure the back end codes to run in multiple servers (load balancing).
• Easier to migrate the entire back end service by using any other programming language.
• Easier to add new services without having to wait for the front end team.

The catch

There is only one thing that both the front end and back end developers must agree: how to make the rqeuest to the API interface and what is the responses.

This is great. Isn't it?

Conclusion

We have been following this development concept for many years and we found it very helpful. It makes both the front end developer and back end developer happier.

Back to #SYSTEMDESIGN blog

Back to #blog listing

Author

Lau Hon Wan, software developer.