I saw in many tutorials that we need to go back to gateway and generate an entity after generating a microservice application with the same entity.
Can someone explain me, the architectural benefits of doing so?
What is the goal of generating those entities again in Gateway?
One of the points of doing that is to implement the Backend for Frontend pattern.
Basically you proxy all calls from your front-end to your microservices through the gateway. For convenience reasons the frontend is packaged together with the gateway.
JHipster just adapted the exisiting entity generators from monoliths to let users generate the backend and front-end of an entity separately on microservices and gateways respectively. Of course this is an optional feature and you are free to use it the way you want.
You can use different ways for different purposes to reach the service a microservice is offering to you. As mentioned here you don't have to use AngularJS or Angular, but you can also use React and/or Ionic.
In general you can use more than one gateway to all or only a choice of microservices per gateway (a very good example implementing different gateways is shown here).
Related
I've used microservice architecture for years. I've also used serverless functions for years. But I've never found a neat was to present groups of serverless functions as microservices.
Server based approach
I'm a big fan of presenting HTTP APIs (internal and external) using OpenAPI specs. It enables a self-updating UI (Swagger) as well as the ability to generate SDKs.
In a server based architecture, each microservice would have its own OpenAPI spec (generated using something like Springfox, Swashbuckle etc). Then the overall system's public API Gateway would have its own spec, exposing the relevant internal calls.
Serverless equivalent?
I'm aiming to implement a serverless-microservice architecture on AWS. Replacing webserver-based logic with collections of Lambda functions isn't an issue. My question is: How do you present a collection of related Lambda functions as a microservice?
Are private gateways the right tool for the job?
I've considered using private API Gateways to present groups of Lambda functions. This would mean having a public API Gateway, pointing to multiple private Gateways. I've not seen this approach used before (which is why I question it being the optimal answer). I'd welcome any criticism of it as well as alternative ways to achieve the same thing.
My phone buzzed this morning and this Medium article popped up.
Seems to validate the private Gateway approach. Credit to Mehmet Ozkaya.
I'm going to begin a new project of microservice and want know about patterns that I might wan't to implement on my new microservice for that I could scale, don't have problems with load balance, have an good service with resilience.
I looking to know about patterns that might microservices should implement
Also could you provide some indications for Java microservices application?
For solve some problems that was said: [1]
Architecture: You could build small microservices as it can be, so that the scale be right focused on need to be.
You could set a Discovery service for registering the applications instances, with that making easier to the client access the right application when are lots of instances of the same service (Netflix Eureka / Spring Cloud).
You could set a Configuration outside the code source of the code, so that all the instances can be configured without human intervention right on the running code (Spring Cloud Config).
Set a way the check the health of the microservice with ease.
I circuit breaker for clear the anomalies microservices instances (Spring Cloud / Netflix Hystrix).
and following as say the Twelve-Factor App.
With lots of another things that you need to that care when building a microservice, suggesting the reading the book, if you'll use Java for building microservices Spring Microservices in Action By John Carnell , if you i'll implement in another programming language this other could guide you, Microservices in Action by Morgan Bruce and Paulo Pereira.
[1] (https://www.amazon.com.br/Spring-Microservices-Action-John-Carnell/dp/1617293989
I am using AWS API Gateway and would like to construct multiple API's for a set of Spring Boot micro-services that exist behind the scenes, but do so automatically.
For example, lets say I have a User and Contract Micro-service and they expose a simple CRUD, I would like to make 2 API representations inside the API Gateway for these 2 micro-services however they will be in the context of an Admin and a User.
The Admin API would have full access to all operations (CRUD) of both micro-services, however, the User API would only allow Read from both micro-services.
My question is about maintaining the representation of these 2 API contexts (Admin and User) is there any way to easily generate the swagger(s) that I would need that I can synchronize the API Gateway with without having to manually maintain this? Or is there a better approach that others are doing that im missing?
I have found spring fox which I was able to use and generate the swagger defs for the API at the microservice levels, but this only satisfies the Admin Use case and not the User one from what I can tell.
Has anyone found an elegant solution to this?
In a micro service architecture, Is it good to have separate DAO services for all the Business services or should I have all the layers intact in the service. In my case, I am building a small Banking application where in I have below services
cbs-accountsummary
cbs-payments
cbs-accounts
cbs-loan
cbs-deposits
So should I really require below services as well
cbs-accountsummary-dao
cbs-payments-dao
cbs-accounts-dao
cbs-loan-dao
cbs-deposits-dao
Or is it fine to have DAO as part of business services. I am really wondering how it goes in real life applications.
In micro-services architecture you split your Domain to micro-services and each micro-service will have its own: api, business logic and data access.
Your example
In your case for example the micro-service "cbs-payments" will have its own API exposed, as well as a business layer(the domain logic of the payments domain) and data access layer. The micro-service will be responsible for the whole scope of the request from api to data persistence. This could include api's, business logic, cache, database and other things.
Lets say if you have a Create payment api call. You would call your micro-service REST api like POST api/payments which would process the request, apply some business rules(validation and others) and save it to the micro-service specific database. All that code would be in your micro-service.
The confusion
Maybe your where working with systems where the the architectural split was not done based on the domain but on some other criteria.
Usually micro-services are split based on some Domain boundaries like in your example. Each of these micro-services are isolated. Regardless of business logic, data access logic or any other logic it is still part of that micro-service.
Usually people use DDD(Domain Driven Design) with micro-services. It is also a common approach to use Repository and Unit Of Work design patterns. You could create Generic Repository/Unit of Work classes which help in database interaction. If you are using micro-service architecture you can extract these generic implementation to some library and use them in each micro-service(extend them if needed). Still you would use that code in your micro-service code.
As already said, I would not go for separate DAO-Services. A Microservice should control all aspects for the bounded context it is responsible for, this includes persistence.
Imagine, if there would be seperate DAO-Services, what would prevent a client from modifying, via said services, the data of the Microservice itself? The Microservice applies business logic onto its domain objects and persists them or not (in case of business rule violation). You never want this to be circumvented. See "cohesive behavior" of Sam Newmans book Building Microservices.
We are developing our application which probably is going to consist of about 20 Microservices. We are considering to use Pivotal Cloud Foundry to manage our Microservices and make it easier to have a platform for deployment and health check - amoung others.
About 12 Microservice will render HTML and now we want to know how we can compose all these services to one UI and present it to the client. Does Cloud Foundry a plugin or somehow solves the UI issues for Microservices? Does PCF generates Composite UI?
Does Cloud Foundry a plugin or somehow solves the UI issues for Microservices? Does PCF generates Composite UI?
No, the platform does not do this for you. It only handles routing requests to your apps.
About 12 Microservice will render HTML and now we want to know how we can compose all these services to one UI and present it to the client.
You might look into using a proxy app in front of your microservices. The proxy would just be responsible for presenting a unified front for your clients and combining all the backend services together.
Netflix Zuul/Spring Cloud Zuul or Spring Cloud Gateway might help with this, if you're using Java. I've also see people use Nginx as a reverse proxy to do similar things.
At the end of the day, you're going to need to figure out what works for your particular microservices & clients side apps though. I don't think anyone can give you a definitive answer to your question, at least not without a lot more information.