Decoupling the front end from back end

Published on: 26th Sep 2017

Updated on: 10th Jan 2022

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 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 from C# to golang or Node.js, it is going to be very challenging.

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.

What we have done differently

We decoupled the front end from the back:

• The front end should be build from the scratch with HTML, CSS + JavaScript.
• The back end will be develop 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 query, processes by the web server and then response back to the client.

The benefits with this approach

To 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.
• Easeier to develop a new front end for a new target device such as kiosk machine.

To the back end developer,

• They may focus on processing the incoming request and response with the appropriate data.
• 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 using load balancing.
• Easier to migrate the entire back end service by using any other programming language.

The catch

There is only one thing that both the front end and back end developers must agree: the API interface. Whether you want the REST API or a simple URL API (please refers to System design with ASHX web services (JQuery + AJAX + partial HTML UI) ).

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.

Jump to #SYSTEMDESIGN blog

Author

Lau Hon Wan, software developer.