I am refactoring an application to be a little more microservices oriented, so my goal is to have a common app host project that handles auth & session and front ends services, and then each microservice solution will contain that shared app project and then include projects for Services, DTO’s and Persistence associated with that “subject area” of the architecture. We’ll then deploy instances of each of these solutions as appropriate for load and fault tolerance.
Is this a reasonable approach and are there any restrictions or design consideration on how a shared apphost project might discover services across different solutions?
Target runtime is dotnet core on ECS if it matters.
If your Services are split across multiple .dlls, you can just add the Assemblies in ServiceStack’s AppHost constructor, if you’re splitting your System into multiple Microservices than we recommend using the Service Gateway which allows you to make intra Service API calls with the same API irrespective of whether it’s calling an internal Service or external Service. Built on top of the Service Gateway are some Service Discovery solutions that take care of automatically discovering available services and will automatically route them to the appropriate Service.
ServiceStack’s lets you “design for Microservices” by being able to split Services across multiple .dlls and decouple inter-service dependencies behind its Service Gateway so you can delay physically decoupling your architecture into multiple deployment units since it’s naturally and easy to do once you identify there’s value in it.