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?

  • 9
    (1). Yes. It's normal now a days to go that way.
    – Laiv
    Commented Dec 4, 2016 at 13:59
  • 5
    (2). So - I must be cautious when starting to use technologies in manner which is not widely used. Yes, you must be cautious if you are planning to use a hammer to pitch silk. Maybe it's not the right tool.
    – Laiv
    Commented Dec 4, 2016 at 14:02
  • 3
    Be aware that decoupling in such a rigorous way creates significant upfront development cost. You need to get some concrete value out of that.
    – usr
    Commented Dec 4, 2016 at 17:50
  • 2
    Also note that you can never directly expose your domain to the browser. This creates security issues and the data will not be suitably formatted for display. You will need to create a special purpose (REST) interface just for the JavaScript to call. And that's coupled.
    – usr
    Commented Dec 4, 2016 at 17:54
  • 1
    Spring has the annotations PathVariable, ResponseBody, RequestBody and RestController (You should check them out). They make developing Ajax based JSON/REST web applications very, very easy, which makes Spring a great backend for SPA. I strongly believe that separating frontend and backend that way is the better choice: The classical JSF applications I had the "pleasure" to work with were a mess.
    – ASA
    Commented Dec 5, 2016 at 12:07

3 Answers 3


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.

  • 11
    "security is harder to do when all the code is on the client;" ehm, isn a big advantage the opposite, security is easier to do, because the is a very clear layer you have to protect which is designed in a logical and easy to understand manner. Commented Dec 4, 2016 at 16:26
  • 3
    @DavidMulder: with the clear layer security is harder to do at all, but easier to do correctly. Without a clear division you can whip up something that's plausible but wrong in next to no time ;-) Commented Dec 4, 2016 at 16:31

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.


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 :

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.