Separating the front-end and the API server

Introduction

JHipster is a “full-stack” development tool, and its goal is to make you work efficiently with your front-end code (Angular/React) and your back-end code (Spring Boot).

However, it is a common requirement to separate the front-end and the back-end codes, typically because they are developed by different teams and have a different lifecycle.

Please note that this isn’t the default JHipster way of working: this isn’t complex to do, and works well, but this is an advanced topic. If you are just getting started with JHipster, we recommend that you begin by using our standard way of working.

Generating only a front-end or a back-end application

You can choose to generate only a JHipster back-end or JHipster front-end application. At generation time, this is only a matter of choosing flags which are described in our application generation documentation:

jhipster --skip-client will only generate a back-end application (this is typically what JHipster microservices are)

Directory layout

When working on the front-end, there are 2 directories you need to know:

src/main/webapp is where the client application will be developed

target/www is where your client application will be packaged

If you have separate teams working on the front-end and back-end, you have two solutions:

Both teams can work on the same project. As the directories are separated, there won’t have much conflicts between teams. To make things even cleaner, both teams could work on separate branches.

The front-end code can be stored in a specific Git project, and then imported into the main back-end project as a Git sub-module. This would require to move the client-side build scripts, but this is a simple refactoring.

HTTP requests routing and caching

Once the front-end and back-end have been separated, the issue will be how to handle HTTP requests:

All API calls will use a /api prefix. If you are using Angular, there is also a specific SERVER_API_URL constant, defined in the webpack.common.js configuration, that can enrich this prefix. For example, you can use "http://api.jhipster.tech:8081/" as a back-end API server (If you do this, please read our documentation on CORS below).

Calls to / serve static assets (from the front-end), which should not be cached by the browser.

Calls to /app (which contains the client-side application) and to /content (which contains the static content, like images and CSS) should be cached in production, as those assets are hashed.

Using BrowserSync

In dev mode, JHipster uses BrowserSync for hot-reload of the front-end application. BrowserSync has a proxy (here is its documentation) that will route requests from /api to a back-end server (by default, http://127.0.0.1:8080).

This only works in dev mode, but this is a very powerful way of accessing different API servers from the front-end.

This Docker image will configure an NGinx server, that reads the static assets from target/www: this is where the JHipster front-end application is generated by default. In production, you will probably have a specific folder for this.

It also reads a ./nginx/site.conf file: this is a NGinx-specific configuration file. Here is a sample site.conf: