I'm currently having a look at JHipster.
What I could not figure out is how JHipster handles environments like dev, testing and production.
This includes:
server (configs like db or other app specific configurations)
client (Angular4, configs like api endpoint)
In angular-cli projects I'm used to environment specific configuration files (environment.dev.ts, environment.prod.ts) that can be defined at build (ng build --env prod) but since angular.cli does not seem to be the prefered way on JHipster there must be another solution to this.
So my questions is:
how to configure environments (server and client)?
how to specify the environment (server and client) during build?
If you are creating a standalone application or using the JHipster gateway bundle architecture, you can parameterize your Angular 2 app through webpack by using DefinePlugin. I detailed the steps to this process here: Environment-based properties for Angular 2 App Served by Webpack?
JHipster packages the client within the server as an executable jar so there is no need for different API endpoints between different environments on client side as long as you use /api.
On server side, JHipster uses Spring profiles which can be set dynamically and point to external configuration files (application*.yml files). By default JHipster comes with 2 main profiles dev and prod, but there are also others like swagger and no-liquibase that you can combine with dev or prod. You can define your own profiles too.
If your client app needs to access some external API endpoints (e.g. Google) that are different between environments, you can do it in 2 ways:
- retrieve the active profiles from server API using /api/profile-info and then initializes your endpoints in client code.
- create a new endpoint in server (e.g. /api/configuration) to fetch your client configuration
Then there are 2 kind of builds triggered by maven/gradle profiles: dev and prod.
For a newcomer, the most important thing is probably to understand Spring Profiles and application properties, these are not specific to JHipster.
Related
For an example, I have one angular ui project that fetches values and perform operations.
I have one backend API project in .Net Core and now I want to reuse angular ui project with node js.
Is it possible?
How to configure it and which are the main points to take care that angular project support both.
How can I deploy it?
Angular is a client side application that run's in clients browser, as long as the REST API or service you connect has Same API endpoints and same object models and authentication etc everything will work as intended.
REST is platform independent like the web services and also language independent. It doesn't matter if you use .Net Core or some nodejs framework.
Once the angular application is build ( ng build --prod) you get a bundled application files in dist folder you can host these files in any web sever just like you host normal html file.
The only change you have to make in the the Angular application will be to change the host URL (if there is any change) normally configured in environments folder
Take help of environment file and change the api as per your requirement.
I am creating my first app node express app with angular 7 on the frontend to be deployed in production. I have below question?
What folder structure is preferred, should I create separate
projects for node and angular or same project(server.js in the root
of angular project and server folder to create express server
files)? What is the preferred one and I have to checkin the project
in one folder of svn.
Should I use babel and create the node server code with es2015 or
continue with old approach?
Its all up to you, what I am doing is I have sepreate directory for Angular and Node projet
project
|
client - Your anguar project
server - Your Apis and server side coding (Only this folder require at productino level)
Then we can create a gulp file and task to gulp that Build my client
project and put that build folder inside the
server -> public
Now only server can be use to production where Build will be render as static.
And next to authentication and autherization process you can follow JWT based permission .
Generally I would say that separating your client and server code into separate projects is preferred so that you do not have to release both your client and server at the same time when you make a change to one or the other. The rest of my answer is based on the assumption that you would separate the two sides into different projects.
As far as structuring your server side Express-based application, check out this link for some guidance on how to handle your situation. See the answer to the first question about different approaches to how to structure your Express application for different deployment scenarios. Also, if you use the latest LTS version of node, you will not need to use a transpiler to convert your files to Javascript because the Node environment will handle that for you.
As far as structuring your client side Angular-based application, check out this link for a very detailed discussion about best practices for structuring your Angular application.
I would prefer following, in case in future you need to separate the API layer with client you can do it with ease,
project
|----client
| ---client-template //All UI code like .css/htmls and node process initiates from here
| ---client-angular // All the directives and controllers goes here
| ---client-service //Service layer, All the API call to server goes here
|----server
| ---server API's // separated by its own module if any
|--- you API modules and so on..
This will help you to have flexibility over client and server integration without any tight coupling. Also easy to maintain and debug.
Answer 1: you should make two separate folder/repository structure for frontend and backend.
let's suppose your application grows fast at that time you want to scale your backend and you want to host your Angular app as static web app using Amazon-S3 so at that time it will be very easy to manage this.
May you want to use CICD, in that case also it will be good if your separate folder so you can create separate CICD jobs for backend and frontend.
May be your company hired some developer which is either expert in frontend or in backend only. in that case your company don't want give them unnecessary code access. so separate repo will be an easy option for this case. (this may be Depends on your team and company's approach for development)
Answer 2: I recommend go for es6 or es6+ features.
latest node.js version is supporting some of the features of es6. for example
- spread operator
- destructing
- classes (you can use OOPs)
- arrow functions
- let, const
- async await and etc
you can use babel if any other feature which is not supported by node.js. there could be may reason for using babel, but i want to know which specific feature do you want to use with babel? so i can explain according to that.
I have used the following approach that bind the Angular Application and the Node server as a single unit.
Steps for creating the project structure is:
Create a new Angular project with the CLI.
Create a server.js file in the root directory of the project and configure it to render the contents of the dist/ folder on the / route.
You can refer the link for the server code: https://github.com/nikhilbaby/node-server
Running the server
I usually run the project with ng build && node server. This will make sure that the angular application is build first and after that node server is started.
In our team, we have an internal node application built using Express API. We have a config files written using dotenv format and packaged along with our deployment process. That means whenever I change any config value, I had to deploy my entire application code again even if there is no change in code and start the service.
I would like to ease the deployment process. So far, I've the following approaches in my mind:
Pull-out the config files from the application code package and deploy only config if there is change in config, and restart the application service. This would require the outage, but no build and deployment of the application code.
Put the configs in the DB like Redis / Mongo, and read from there. If there is a config change, do the change in DB and call /reload api which we can build in our application to reload the config object. I'm not sure about the side-effects of this approach.
Kindly please share your experience and how did you overcome.
I am evaluating the JHipster microservices architecture.
Where do I need to write my application specific configuration in jhipster-registry-master?
How can I get this configuration from Angular (gateway) and from Java (Microservice)?
Is there any documentation/example?
For java spring-boot, this is documented in Spring Cloud Config Server docs you have to choose either filesystem backend or git backend (but not jhipster-registry-master), for the angular part you could consume a REST resource on your java backend exposing a part of your configuration (you can see an example in ProfileInfoResource.java)
I develop an application in Angular 2, mongoose, gulp and node.
What hosting service could you use?
What are the steps to mount an application of this type on a hosting server?
Thank you very much!
I recommend using Webpack for handling hosting.
With Webpack it is easy to setup different environments (dev, prod) with many configuration options. It provides a development server and many options to prepare your app for hosting. It supports tree-shaking (dramatically reduces the size of your application) and manages all the loading of your assets.
Hosting depends on your country. You can theoretically use any provider. Angular2 apps do not require any special configuration / plugins / services.
The steps are quite easy: Build your app, configure Webpack according to the guide found in the link above or here(Very nice description of how to build your application for production in an efficient way), and then start the production build via npm as described.
After that you could just drag your application to your ftp server and link the index.html. That's it!