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.
'Framework' is a generic term.
Django is a web development framework built on top of Python. It provides commonly needed tools for creating a website: tools like connecting to a database layer, running a development server, rendering views, and routing requests to the correct controller are all provided by the framework.
Rails is a similar framework, just built on Ruby. Theoretically you could create a web app in just Python or just Ruby without the framework, but it would be a pain to rebuild all those tools from scratch.
Angular is a front-end framework for creating interactive HTML views out of standardized data structures - take a look at the section on their home page about 'wiring up the backend'. Angular does not have a way to 'save' data beyond basic Javascript tools like saving to cookies or local storage; it needs a backend system for that. It uses some of the same language to describe code organization (such as "MVC") but it is not providing the same tools.
Front-end frameworks do not do the same things as back-end frameworks, and indeed, sometimes one front-end framework doesn't do the same things as a different front-end framework.
Web developers use 'front-end' and 'back-end' frameworks for handling two different types of interaction with the user.
django can do both frontend as well as backend.
Unless I dramatically misunderstand Django's abilities, it cannot create dynamic in-page interactions such as modal pop-ups, live editing, etc. It can render HTML, yes; but it cannot make any text you type into the text box also appear on the page simultaneously.
Back-end frameworks such as Django, Rails, or Symphony are used to handle idempotent browser requests and HTTP calls. You load a page, the framework inspects the url that you have requested and builds the entirety of the page, piece by piece, and returns the whole thing to the browser. (APIs too)
There are some exceptions to this, but in general when you "navigate" around the internet, "back-end" systems are handling those requests. When you see the URL change and the whole browser window whites out for a moment, that is this type of navigation.
"Front-end" frameworks are more important for handling in-page user interactions. Things like modal pop-ups, loading more data via AJAX without loading a new page, submitting a form and displaying a message without redirecting, hover effects.
The simplest front-end framework that you can use is just HTML plus CSS. If you need more complex interactions, you can add Javascript to those tools. If your javascript is complicated or you are recreating common patterns, you might add jQuery for it's animation tools.
If you find yourself reimplementing an entire application (replacing the entire content of the page when you click certain links or take certain actions - a "Single Page App"), then you might use a Javascript framework like Angular to build up those interactions.
Rarely will you see a front-end-only web application. Just about any website or application will require some sort of persistent data storage - logins, page content, comments, product data, user-submitted content, anything. The backend framework then acts as a communication layer between the database and disk and the front end. It could do as little as providing a simple REST API for accessing/creating/editing data while the Javascript handles all templates and HTML, or it could build out HTML partials, and the Javascript front-end assembles them together, or it could assemble the entire page, and Javascript is used only for animations and occasional Ajax requests.
Best Answer
The only scenario where I can see that configuration is when main API is not published with a public subdomain, so you may mask it publishing an intermediate public “backend” to proxy requests to the API in the private network OR you have a front end-backend (Let’s say a CMS with a different ad-hoc front end in AngularJS, React or any other Client-Side technology ) that consume services from other API, so you have a mix of CMS functionalities and data coming from the other API, I have seen both cases.
Most CORS problems come from misunderstanding of this mechanism. https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
If API is publicly exposed, then you just need to configure the Access-Control-Allow-Origin: For the calling subdomain (origin of request) so you only have to worry that nothing is changing headers when they’re sent.
Of course CORS serves for the purpose of safely sharing data between different servers, hosting different applications, as API may reject any request not coming from the subdomain specified at Access-Control-Allow-Origin:
Otherwise having two backends with different or complementary business logic may result on a disaster, as any change done to the front end may easily result in changing code in the two backends which makes it harder to maintain.