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

Question

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?

Answer 1

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.

Answer 2

The answer to your question is simple. Yes. What you propose is a sound approach. But then, what I think you want to ask is whether it's a better approach, and unfortunately, none of us can answer that for you. The factors involved span too many facets that without divulging everything about both your organisation and the product requirements, no real conclusion can be made. I think you already know what to do anyway.

Answer 3

Normal with caveats.

front end javascript frameworks are limited in what they can do. If you create raw apis for use by multiple applications, they usually require some server side processing of the raw api calls into view models that work with that particular application.

Hence a 'normal' architecture might be :

database
business logic services (dll)
api exposing business logic
server side website exposing viewmodels and functionality via json rest endpoints
client side javascript implementing ui

Now if you only have the one web application you can cut out the 'api exposing business logic' layer and just have the server side web code call the business logic directly.

Because youve separated the business logic into its own library, its still decoupled from the ui logic and you can always add a service layer later.

Similarly, because the api service is called by server side code, you are not limited http communication. (although this is pretty much universal now)

Additionally, having the javascript call the same host that its served from means you dont have to muck around with cors