Hello Everyone. This will be the first part of my multi-part series which will explain the concept of microservices and how to orchestrate calls between them keeping in mind things like performance, latency and scalability.
Hi…I want to understand
1.How UI/HTML or front-end will be developed in microservices architecture as it will be a entire deployable unit and services used in it can be deployed separately.
- In microservices architecture, How Git repositories are maintained as each microservice is independent of each other. So will each microeservice will have separate git repository.
this definitely one for the ages. Microservices are here and we can’t keep quiet about it.
- The UI component can also be deployed in a micro-service architecture. There are different ways to do this. One approach is to break down the UI into static components and dynamic functions. The Static components (html, css, jquery libraries, images) etc can be hosted on Apache or Node JS server . The dynamic part of the UI that contain logic to parse, filter, format any data sent by the backend can be written and deployed in NodeJS. The Dynamic UI component is what will talk to the backend servers.
By doing the above you can scale the front-end (dynamic) and the backend (data) components independently. Also, you can improve static content caching and content load latency by adding a CDN(content delivery network) in front of your static content.
The other approach is to simply combine the static and dynamic content and deploy them on Node or other similar servers.
The dynamic component also sometime takes care of the Authorization & Authentication with the backend servers and any role based access rendering on the UI layer based on the permissions/roles returned by backend.
- You are right. The idea is to have separate git repositories. Each service will have its own git repo. Each team member from each team will be able to work on each service independent of the other using git branches. Sometime, the codes changes do span across multiple services, which means pull-request across multiple git repositories and coordinated deployment of micro-services to release a feature.
Thank u for your response.
Few more doubts
In microservice architecture each service will have own database so then how relational database queries will be handled? There will be no joins? If I have to display data suppose from master database and transaction tables then how microservice will be designed?
Microservices are stateless or stateful?
The idea behind the microservice architecture is to be able to scale different part of an application (constituting of multiple micro-service) independent of each other. A ‘user’ micro-service may have a different traffic pattern than a ‘subscription’ micro-service. Based on the traffic pattern and request SLA’s each micro service tend to choose their own databases (could be no-sql or sql).
Microservices should be stateless. Most of the micro-services are designed using REST API and REST API interactions are meant to be stateless.
Where API Gateway and API Gateway Manager comes in a picture for microservices?
Is it possible to have multiple API Gateway?If yes, then what will architecture will look like?