To expand on this existing question Microservices: Worker roles, APIs or both?:
I have seen mixed examples of Microservices implemented as worker roles processing requests off a queue and/or as APIs (REST).
Supporting asynchronous scenarios, a queue can be utilized, with a simple dumb queue listener forwarding the request to a Microservice REST API, where as synchronous scenarios would call the REST API directly.
The term Microservice is vaguely defined I think; do people consider them APIs (e.g. RESTful services) or as any abstract service processing requests, however that request was provided ?
What would we use for naming conventions to differentiate between a service that is running as an API, or a service running as a background worker thread (that pulls from a message queue or runs tasks at intervals)?
This is important to differentiate so that the intent is clear, in that the hosting technologies of web applications allow multiple workers to be span up in parallel, whereas we may want a single worker thread running at any time performing scheduled maintenance tasks.
Further info below.
Scheduled background worker or ServiceProxy
In some cases we may proxy the scheduled background worker to call into the service, i.e:
- Run worker
- Dequeue while not shutdown
- Post into service -> https://myservice.example.com/assets/123?uptime=100&cpu=54
What would we call such a ServiceProxy background worker? I guess if we are worried with concurrency issues and multiple of these background workers running in parallel, then this can be resolved in the call into the service itself.
Client library
I propose a client library to contain:
- Methods to call the service to get information
- Methods to post to the service (via webservice, transparently handled within the function)
- Methods to post to the service (via message bus, transparently handled within the function)
For points 2 and 3 above, there would be no indication other than the function name of the details of how the data is sent i.e. RegisterEndPoint(Guid id, string name) using a standard WebAPI call internally, and SendUpdate(Guid id, HealthPoco stats) using message bus... the client would consume the library without concern for the details.
Project Structure
So far i have as a project structure:
ExampleSolution.Assets.Service- for a WebAPI or gRPC service, multiple of these can run in parallelExampleSolution.Assets.ServiceProxy- this is a background worker, generally we want one runningExampleSolution.Assets.Client- this is the client library that allows communication with the serviceExampleSolution.Assets.Common- related common info such as data contractsExampleSolution.EndPoint.CoreAgentApp- endpoint application running on Windows or Linux workstations, there would be other services such as ExampleSolution.Warranty.* etc repeating for Service/Client/Common etcExampleSolution.Managagement.Common- common data libariesExampleSolution.Managagement.App- functions to call into each individual service to build up the viewsExampleSolution.Managagement.Website- the actual hosted Asp.net MVC application including all web pages, calls theExampleSolution.Managagement.Appfunctions to retrieve views and perform actions
I would probably put ExampleSolution.Managagement.* and ExampleSolution.EndPoint.CoreAgentApp projects in a separate folder to indicate these are "applications" and seperate away from the "services".
I have seen https://github.com/dotnet-architecture/eShopOnContainers which is clear in how the services are organised, but not clear how scheduled tasks would run:
A project showing both styles of service and SignalR or other message bus service and their project naming conventions would be useful.
I don't want to post off topic or against rules, if anything is vague or intent of the question not clear please let me know and I will expand further.
