Web Design – Decoupling Backend and Frontend with REST API

apibackenddesignfront-endrest

I am creating new business web application and I want to achieve:

  • Use the best technologies from their respective realms. I want reliable backend framework with solid ORM. And I want the most advanced SPA (single page application) framework with the use of most up to date HTML and Javascript features for the frontend application
  • Expose backend entities and business services for the use from different types of applications – e.g. web applications, mobile (Android) and possibly other types (smart devices, etc.)

So – to satisfy both requirements I am inclined to completely separate my application in backend and frontend applications and organize the communication between them using REST API (JSON). Is this sound approach?

Such separation is not obvious design solution, because many web application technologies have integrated view layers where the server side application more or less control the generation of the view and partially handles the responses from the view (e.g. SpringMVC with view layer, PHP Yii with view layer, Java JSF/Facelets completely saves the state of their components on the server). So – there are many technologies around that propose more strong coupling and promise faster development time and more standard path journey. So – I must be cautious when starting to use technologies in manner which is not widely used.

As I understand then completely separated SPA frontend usually arises from the necessity to use third party API. But is such decoupling sound design when both backend and frontend are developed by one company?

My choice of technologies currently is Java/Spring backend and Angular2/Web Components/Polymer for frontend – if I am allowed to say this. But that is irrelevant for this question, because this question is about general design and not about the choice of concrete technologies?

Best Answer

Is it normal design to completely decouple backend and frontend web applications and allow them to communicate with (JSON) REST API?

Yes it is normal. But it's normal only if you need to have that sort of separation and you are not forcing this setup into your overall application.

A SPA comes with a few issues associated with it. Here are just a few that pop in my mind now:

  • it's mostly JavaScript. One error in a section of your application might prevent other sections of the application to work because of that Javascript error. With pages served from the server (SpringMVC, PHP, etc) you reload a fresh section;
  • CORS. Not necessarily mandatory but often the back-end is on a different domain name than the front-end. So now you have to deal with browser security issues;
  • SEO. Do you need this? Is your site public? Google can understand Javascript and try to make sense out of your site, but you basically give control to a bot and hope for the best. Taking back control might mean having to rely in other tools like PhantomJS.
  • separate front-end application means separate projects, deployment pipelines, extra tooling, etc;
  • security is harder to do when all the code is on the client;

Sure, there are SPA advantages too:

  • completely interact in the front-end with the user and only load data as needed from the server. So better responsiveness and user experience;
  • depending on the application, some processing done on the client means you spare the server of those computations.
  • have a better flexibility in evolving the back-end and front-end (you can do it separately);
  • if your back-end is essentially an API, you can have other clients in front of it like native Android/iPhone applications;
  • the separation might make is easier for front-end developers to do CSS/HTML without needing to have a server application running on their machine.

So the thing is that there are advantages and disadvantages to both approaches (SPA vs server pages). Spend some time on researching both options and then choose based on your situation.

Related Topic