I am using Jhipster and really like it.
Instead of generating my microservice frontend integrated inside the gateway, I would like to generate a separate frontend microservice.
Instead of having gateway -> µservice-backend, I would have gateway -> µservice-frontend -> µservice-backend
My use case :
userA has a physical device devicev1. userA logs in on the gateway. He can see the application for the devicev1.
userB has a physical device devicev2 (different features than v1). userB logs in on the gateway. He can see the application for the devicev2. (the backend is a different µservice for v1 and v2)
userC is using a virtual device. He will see and use again another frontend + backend
Some researches :
I understand this is a hard to maintain feature because we would have to inject the "µservice-frontend" module inside the gateway. (And now there is Angular + React).
The question was asked in 2016 :
https://groups.google.com/forum/#!msg/jhipster-dev/8VfS2ma_lX0/NySAdWJhEgAJ
https://github.com/jhipster/generator-jhipster/issues/3667
I suppose I can still do it by generating a "client only" application and link it separately (rewrite the url), but I loose all the monitoring/registry/security jhipster stack.
Sooo, I won't do it and keep everything in my gateway.
I could also have multiple gateways, but I was more willing to have load-on-demand modules, in the same application.
More than one gateway in jhipster
To keep it clean, I can create different angular modules for my load-on-demand part. I can use git mono-repo to separate each version in separated repository and compose before compiling. They are a lot of solutions, but I would like to use a more µservice way.
Any solution or architectural good practice?
Thank you
Related
I'm building a graphql gateway service, which merge multiple services into one graph, using Apollo/Node/Express and following the Apollo Federation model. Initially, most of the services I'll be connecting to are REST services.
In all of the examples I find (e.g. here), I see that the gateway project runs multiple instances of ApolloServer, one for every REST service plus one more for the gateway itself, and runs them all using a package like concurrently. Basically the gateway project runs n+1 ApolloServers. Having all of these servers running seems strange to me, but I'm pretty new to this whole ecosystem.
I'm not clear if this is just for demonstration purposes, or is this also how it's implemented and deployed in the real world?
I hope that those were just examples, and are not the expected pattern.
If you need multiple GraphQL Services, each one of those would be served as a separate Domain Graph application, as its own project. Then an additional service (the gateway) would consume all of those applications and expose a single unified GraphQL API.
Planning to migrate my PHP APIs to Graphql using Apollo Federation. After a bit of research, I see it is done using the following way:
My questions are:
Is there any better way to create the federated services so it is not a separate layer (1 for each REST API)? Maybe something close to the previous schema stitching approach where all can sit in one place and be stitched together at the end (instead of a specific federated layer for each service).
If this is the recommended way, how do I deploy this infrastructure? From the diagram, does it mean I have 5 instances running to cover all of the services?
Is it recommended to run Gateway and Federated services all inside one instance (from diagram - 3 servers running in one instance)?
Let me know if it helps.
Federated services are great when you want to break the monolithic structure of the non federated implementation of apollo server. It can be designed by incorporating the micro-service best practices. Instead of blindly having one federated service per rest endpoint, you can have federated services based on the functionality the service is suppose to take care. One service can call multiple rest endpoit. This would provide you better control on scaling, securing and managing services at infrastructure level. An example can be as simple as amazon where item browsing hits will be way more than buying transactions. In this case you can have one federated service which provides browsing data where as another one can for managing transactions. Then you can scale one to multiple instance to handle user load and have additional security in place for the one hadnling transactions.
2 & 3. Yes you would need to have deploy all the components separately. I would recomend to have all the services in the same VPC cluster so that you don't have to worry about network layer security. If the services are deployed across multiple clusters, it will be adding handling firewall and https/tls for every request, which would cause unnecssaery delay becuase of network call. Although it would be in milliseconds but can be easily avoided.
I'm playing around with Docker and deploying microservices to an EC2 instance. I'm going through several tutorials, but every one of them deploys just one microservice and that's it. For example, many tutorials implement some simple controller such as
#RestController
public class LogicOneController {
#GetMapping
#RequestMapping("/logic_one")
public String entry() {
return "LogicOneController stuff";
}
}
in a spring boot app. I can access this api from ec2 such as www.my-ec2-instance/logic_one. But the point of using microservices is to have many other services so how do I go about adding another one? Let's say I have another set of apis LogicTwoController.
Am I supposed to deploy this to another spring boot app? If this is the case, then I suppose we just run multiple containers on the same ec2 instance and access it via www.my-ec2-instance/logic_two and www.my-ec2-instance/logic_three and so on. Is this the right idea?
Microservices should not split by logic_one/two/three. It's sud separate by the business domain which may work in independent, There's much logic in a domain of business.
Back to e-commerce design. Assume that few kind of domain like (login/auth, user, order, shipping).
So each domain may consider as 1 module/domain
Login/auth => the service has a responsibility to manage login token, authorization
User => the service manages all user profile
Order => the service where user can create/execute/cancel... an order
Shipping => the service where you can update/manage the status of shipping with 3rd party...
So, if you have only logic_1, logic_2,... It's 1 service/ 1 module. Above just an example, an actual microservice system is split quite small domain.
a different in Microservice system is, the client(mobile/web...) only communitate with a service call API-GateWay instead of touch to core services (login/auth, user, order, shipping...) directly. It's like 1-stop service lol
Note: An application not using/apply Microservices pattern does not mean that that is not a good design.
I have several Spring web apps, each with its own database.
Now I have to create a web app, that works as enter point for all the other apps..
So if I want to use the web app B I have to pass through the enter point web app. I have to do the login inside this app. To do that I have to sign in against Active Directory.
After that the users can access only to the apps where they have permission, and inside each app they have also some different roles.
what kin of solution can I adopt?
I read about SSO but I'm not sure it is correct.. So, do you have any idea?
EDIT
What do you think about microservice? Is it good for my scenario?
It seems to me you are describing microservice architecture and it is a good way to go. You are likely to need OAuth2 for your authentication. I used this tutorial from Baeldung as a good starting point, although I personally changed the front end from Angular to React but that is down to you.
Your architecture must be micro-service and you might use a API Gateway at front of your interfaces, I suggest you to use Kong - Open-Source API Management and Microservice Management, that have many features like OAuth2
and many other.
Then you can have one or more client-sides that calls one entry point to your services.
I have a single web application that's used by multiple customers that have their respective URLs.
We're in the process of integrating google accounts via Google API with OAuth2.
Right now we have a single project/application registered that's used by all systems.
The problem is if same account is connected on multiple systems, token is overwritten since there is a single project. Same thing if account is disconnected from system A and it's also connected on system B, system B stops working because Google API project/application is the same.
I'm wondering if there is a workaround to have multiple tokens/connections per account with a single application, or the only way to accomplish that is having one project per system and I'll need to programmatically create a project and setup everything accordingly when a new system is built.