Hi,
We are developing systems which consists of several Modules. We faced with some troubles in managing of communication between them. Right now, we have only monolith deployment. That means all our Modules are referenced by single ABP Host Application (which generated by ABP Suite). We referenced all Modules accordingly architecure of layers
Application -> Application Contracts -> Contracts ...
in Host Application. We have Module A which needs to coomunicate with Module B.
- The first question is how to setup references and DI which fit for monolith and microservices deployment Right now, in Module B, we have Background Worker. This worker makes call to module A. For that, in Background Worker class, we reference IBookService of Module B. In monolith it is resolved to BookService, which implemented by module A. What is okay, we do not have authorization issues because authorization is disabled. But when we will place Modules in different service, what we need to do so IBookService will be resolved to HttpApiClient, so call will be made over http?
- The second question is what to do when we will add authorization to endpoints in IBookService? After that, we will start getting auth error, because Background Workder does not have authorization context. As solution, we are going to make InternalBookService implementing IBookService, which will implement logic of BookService. That time, BookService will just call InternalBookService. Thus, Background Worker also access to InternalBookService, instead of BookService which is remote. Question is how to manage DI? In monolith we have BookService registered first, and we will get BookService injected to our BackgroundWorker. But we would want InternalBookService injected instead and be still able to move module B to separate service
- ABP Framework version: v4.3.0
5 Answer(s)
-
0
You can check guide about communication between microservices, it can give some information about it.
-
0
@gterdem Thank yor for reply. But my question is about how to make Background Worker of module A to pull data from module B in way that will work in monolith and microservice deployments
-
0
Some details and rephrasing... The job is placed in application level of module A. The job uses app service from module B. In monotlith, app service interface is resolved to app service, which provided by B. If service has auth protection then job gets error. I would like to apply some workaround... implement internal version of service in B, which will not be exposed to controllers. Internal service implements the same interface (eg IBookAppService). Then, I would like internal version of service injected in monolith deployment. But in microservices deployment client proxy should be injected
Thus, we have 3 implementations of app service interface
- App service - used for controllers. Protected
- Internal App service - used for internal communication in monolith. Internal service implementation is reused by App service for controllers
- Http Client - used in microservice depployment
-
0
Eventually, modules will have running end applications eventually, just as microservices are running (HttpApi.Host projects) themselves.
So, you will need to register the running application (client) to the authority (identityserver) with the related permissions so that you can make client_credential (server-to-server) calls automatically in your background worker application.
-
0
But when we will place Modules in different service, what we need to do so IBookService will be resolved to HttpApiClient, so call will be made over http?
Yest, that's the design of ABP's modularity. This document explains it well: https://docs.abp.io/en/abp/latest/Best-Practices/Module-Architecture It explains all the scenarios.
The second question is what to do when we will add authorization to endpoints in IBookService
Authentication and authorization is automated when you properly configure the client and the server. Create a MVC tiered application. In this setup, MVC UI uses the app service interfaces, but it actually make an HTTP request to the HTTP API server by authenticating and authorizing.
Console test app in the startup template also does that: https://github.com/abpframework/abp/tree/dev/templates/app/aspnet-core/test/MyCompanyName.MyProjectName.HttpApi.Client.ConsoleTestApp It uses resource owner password authentication, but you can easily configure client-secret auth too.
Another document: https://docs.abp.io/en/abp/latest/Samples/Microservice-Demo#identityserver-client here, blogging microservice calls the identity microservice and this section shows the auth config.
We suggest client-secret auth when you want to consume a microservice from a background worker/job.
