search

dotnet / aspire

An opinionated, cloud ready stack for building observable, production ready, distributed applications in .NET
https://learn.microsoft.com/dotnet/aspire
MIT License
3.66k stars 417 forks source link

Add aspire component template #5239

Open alrz opened 1 month ago

alrz commented 1 month ago

Is there an existing issue for this?

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.

alrz commented 1 month ago

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.

davidfowl commented 4 weeks ago

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?

alrz commented 4 weeks ago

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

--

Suppose ProjectA and ProjectB and optionally ServiceDefaults are developed separately, then the structured is factored into:

Solution0

Solution1

Solution2

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)

Solution1

Solution2

The shared packages are already a common practice to avoid code duplication which I think aspire could encourage.