dotnet
Add aspire component template
Is there an existing issue for this?
- [X] I have searched the existing issues
Is your feature request related to a problem? Please describe the problem.
Currently there's distinction between external components and internal projects, in a microservice setting you most likely don't have all the services inside the same solution. A "component template" or "external project" would fill this gap where a service is being developed that others can connect and interact with.
Describe the solution you'd like
The template would be set up in such a way that it can be packaged for other services to depend on. Just like components, these services could be hosted locally or connect to a live instance.
Additional context
Note this is a rough idea perhaps there's a way to do this today but I think it's worth considering it as a first-class building block.
I think what could accompany this is a "aspire library template" as a centralized package that services could depend on. It would include the defaults and all the definition from internal and external components that underlying services in a cluster could use.
Let me know if I am interpreting this correctly: You want to be able to package up a project as an aspire resource and have other services on the team use it?
Let me know if I am interpreting this correctly: You want to be able to package up a project as an aspire resource and have other services on the team use it?
That's exactly correct. To elaborate, right now an aspire project would consist of the following:
Solution0
- ProjectA
- ProjectB
- ServiceDefaults
- AppHost
--
Suppose ProjectA and ProjectB and optionally ServiceDefaults are developed separately, then the structured is factored into:
Solution0
- ServiceDefaults (package, shared)
Solution1
- ProjectA
- AppHost
- Hosting (package)
- Client / Component (package)
Solution2
- ProjectB
- AppHost
- Hosting (package)
- Client / Component (package)
This way, ProjectA can use Hosting and Component packages from ProjectB while being a completely separate codebase.
It's important to be able to connect to a live instance (e.g. staging endpoint) as well as spinning up the image from hosting package.
--
Note Hosting and Component packages don't have to live close to the actual project and can be deployed separately.
Solution0 (shared packages)
- ServiceDefaults
- ProjectA Hosting
- ProjectB Hosting
- ProjectA Component
- ProjectB Component
Solution1
- ProjectA
- AppHost
Solution2
- ProjectB
- AppHost
The shared packages are already a common practice to avoid code duplication which I think aspire could encourage.
Interesting idea that would require some more exploration of what the patterns might look like. Putting on the backlog for now but I'd be interested in seeing any prototypes or further thoughts folks had.
require some more exploration of what the patterns might look like.
Couldn't every component that aspire supports right now be considered as an example of this? Integrations/Components are currently developed only around reusable service/libraries, and this is a request to open that up to aspnet apps as well.
@DamianEdwards is saying that someone should go build it and figure it out, then update the issue with more details. It’s not a focus area for us at the moment, we are bashing bugs and tackling areas of high user feedback.
This is something we want to do, just not now. That could be sped up with more investigation and details about the options.
Off the top of my head I can think of a few things that we would want to understand before making this a template:
- How do you package the application? Custom format? Docker/OCI image/dotnet tool? (PS: I like the idea of putting the OCI/docker image in a nuget package but have yet to try it)
- Is this just about the application or is it about encapsulating dependencies as well? (Microservice as an integration).
- I can see a future where you build an application where your application becomes a hosting integration and you generate a client library (rest/grpc) and that becomes your client integration.
The next step here is to go build a repository sharing what the options would look like and what we might need to change in the core to make it work well.