Generate frontend and backend seperately

[paris0120]

Overview of the feature request

Add an option to generate frontend and backend seperately

Motivation for or Use Case

Currently, the generator has the option --skip-client and --skip-server yet if generated separately by default the frontend server will still connect to the backend server with the same port (SERVER_API_URL = ''). I'm wondering if an option can be added so that the front and back ends can be generated separately (in the case of a monolith app it can be /backend and /frontend, in the case of microservice gateway it can be /gateway and /frontend. Currently, all the scripts are there so only a front-end port is needed for the jdl and set the SERVER_API_URL value in the environment.js to the backend server.

Related issues or PR

• [ ] Checking this box is mandatory (this is just to show you read everything)

[mraible]

Do you want to run your apps on separate ports in production or just in development? The reason I ask is because all the authentication mechanisms (accept for JWT) rely on cookies to communicate between the frontend and backend. We do this because JWTs aren't that great for session tokens.

[paris0120]

Do you want to run your apps on separate ports in production or just in development? The reason I ask is because all the authentication mechanisms (accept for JWT) rely on cookies to communicate between the frontend and backend. We do this because JWTs aren't that great for session tokens.

I'm moving a monolith app to a microservice. I'm planning to have separate ports or servers in production so that I can update the frontend without restarting the backend. I'm currently developing with oauth2 (keycloak) and following the development tips from https://www.jhipster.tech/using-angular/. Based on https://www.jhipster.tech/separating-front-end-and-api/ I believe that I need 2 ports or servers for the frontend and backend for the gateway, right?

Also, I find that if I use --skip-server for a microservice app, the generator still generates some files for microservice (basically the node_modules and profile files). What are these files for?

[mraible]

Our current OAuth 2.0 support uses Spring Security and stores the access and ID tokens in the session on the server. We do it this way because it's more secure than doing authentication on the client and it's easier to implement so we don't have to use a different OIDC library for each frontend framework.

If you want to use any of JHipster's existing frontend implementations, you'd need to refactor them to do authentication on the client and pass an access token to the server for data. Or, you could use Ionic for JHipster to create a separate frontend client that runs standalone and talks to a JHipster backend.

[Tcharl]

node_modules contains the packages that bootstraps jhipster itself: don't worry with this one, it's only used for build. which profile are you talking about? I only see spring and maven profiles which are for sure mandatory for backend!

As @mraible mentionned, I would recommend the standard microservice pattern: Oauth2, a gateway, Consul or eureka, and your microservices

[paris0120]

Our current OAuth 2.0 support uses Spring Security and stores the access and ID tokens in the session on the server. We do it this way because it's more secure than doing authentication on the client and it's easier to implement so we don't have to use a different OIDC library for each frontend framework.

If you want to use any of JHipster's existing frontend implementations, you'd need to refactor them to do authentication on the client and pass an access token to the server for data. Or, you could use Ionic for JHipster to create a separate frontend client that runs standalone and talks to a JHipster backend.

Can I run a frontend server as a microservice and point the gateway to that server?

[ndywicki]

For the monolithic version this is possible, as described in the documentation: separating-front-end-and-api

On the other hand it is not a good idea to specify a value for SERVER_API_URL, in addition to the CORS setting, from a client point of view, calls to the backend API must be open to the outside (open firewall routes). The ideal is to close the backend and go through a reverse proxy like Nginx. In this case the API calls will be https://yourdomain.com/api/**

Remarks:

• The NGINX configuration configuration is no longer up to date. Here an up to date sample:

server {
    listen 80;
    index index.html;
    server_name localhost;
    error_log  /var/log/nginx/error.log;

    root /usr/share/nginx/html;

    location /api {
        proxy_pass http://api.jhipster.tech:8081/api;
    }
    location /services {
        proxy_pass http://api.jhipster.tech:8081/services;
    }
    location /management {
        proxy_pass http://api.jhipster.tech:8081/management;
    }        
    location /v3/api-docs {
       proxy_pass http://api.jhipster.tech:8081/v3/api-docs;
    }
    location /h2-console {
       proxy_pass http://api.jhipster.tech:8081/h2-console;
    }
    location /oauth2 {
       proxy_pass http://api.jhipster.tech:8081/oauth2;
    }
    location /login {
       proxy_pass http://api.jhipster.tech:8081/login;
    }
    location /auth {
       proxy_pass http://api.jhipster.tech:8081/auth;
    }
    location /health {
       proxy_pass http://api.jhipster.tech:8081/health;
    }
    location / {
        try_files $uri $uri/ /index.html;
    }
}

=> Off course you can use the default backend URL http://localhost:8080/

• If OAuth2 is used, the server must be configured to use HTTP headers, to correctly generate the redirect-uri for the frontend (and not the backend). So you need to add in NGINX config:

proxy_set_header    X-Forwarded-Host    $host;
proxy_set_header    X-Forwarded-Port    $server_port;

Also add in the application.yml the server config server.forward-headers-strategy=framework to use it:

server:
  servlet:
    session:
      cookie:
        http-only: true
  forward-headers-strategy: framework

[github-actions[bot]]

This issue is stale because it has been open for too long without any activity. Due to the moving nature of jhipster generated application, bugs can become invalid. If this issue still applies please comment otherwise it will be closed in 7 days