We have already discussed choosing a microservice or monolithic architecture in Chapter 1, Introduction to Modern Web Application Development. Here are some more points when it comes to architecture:
- Don't use a microservice architecture if you're a small team. Microservices are about scaling teams more than anything. It's often easier to break up your monolith than start with microservices.
- Use asynchronous messaging in your monolith if you think you may need to refactor to microservices in the future. JHipster provides support for Apache Kafka, which is a good solution for asynchronous messaging.
Asynchronous messaging is the best way of building stateless systems. It is important in a microservice architecture, as you might often want communications to be stateless and nonblocking. Some of the popular solutions for this are Apache Kafka (http://kafka.apache.org/), RabbitMQ (https://www.rabbitmq.com/), and gRPC (https://grpc.io). ReactiveX (http://reactivex.io/) and Spring Reactor (http://projectreactor.io/) are popular abstractions for working with asynchronous systems. Asynchronous messaging also makes the systems loosely coupled.
- If you intend to expose an API to a third party, use API-first development. We now have a good workflow to do this with the OpenAPI generator (https://github.com/OpenAPITools/openapi-generator). Refer to http://www.jhipster.tech/doing-api-first-development/ for more information.
- When setting up communication between microservices with REST, don't put interface code in a shared package; it would tightly couple APIs to their clients, thereby creating a distributed monolith. It is better to have duplicated code than to be tightly coupled.
- With JHipster, it is possible to split the client and server. Refer to http://www.jhipster.tech/separating-front-end-and-api/ for more information. However, think twice before separating them, as this will require you to open up CORS, which makes the security more vulnerable, and such architecture brings its own issues. So do this only if you have a good reason to.
- Use DTOs at the service layer so that you can aggregate entities and define a better API without exposing entities to the client. You will have to enable the service layer for your entities to use this with JHipster.
- Learn the technology stack of your application before you start development.
- Make yourself familiar with the provided toolbelt, such as build tools (Maven/Gradle/Webpack), BrowserSync, and so on.
- Follow the 12 factors of application development (https://12factor.net/).