Feedback & Questions

[yassinebennani]

Hi Team,

I want to express my appreciation for the fantastic work on the Aspire project. It was a pleasant surprise, we are grateful for the effort you've put into it. Thank you!

I do have a few questions about the project's vision and some thoughts on potential improvements:

1-Will Aspire serve exclusively as a development tool, or are there plans for it to be deployable in production in the future?

2-It seems currently there's no straightforward way to customize the Aspire Dashboards application. This limitation can be a bit frustrating. Moreover, the coupling of the dashboard Aspire package with the Aspire hosting package is noted. Could you shed some light on this decision? Is it possible to decouple them, allowing developers to create alternative dashboards or extend the default one?

3-I haven't come across any abstraction packages in Aspire without dependencies. Historically, in .NET Core, the norm has been to provide abstraction packages. Is there a specific reason for Aspire deviating from this approach? I'd appreciate some clarity on this matter.

4-I noticed the existence of the IAnnotation interface but couldn't find detailed documentation explaining its purpose and the impact of adding an annotation to a project. Could you please direct me to relevant documentation or provide more information on this feature?

Looking forward to your insights.

Thank you very much!

[davidfowl]

1-Will Aspire serve exclusively as a development tool, or are there plans for it to be deployable in production in the future?

The orchestration project is for development only. It's not made to be deployed. There are aspects of the system that may be stand deployable in the future though (the dashboard e.g.). We're not building a Kubernetes replacement (there are other issues asking about on-premise deployments).

2-It seems currently there's no straightforward way to customize the Aspire Dashboards application. This limitation can be a bit frustrating.

Time and energy. We want to ship something usable. It's open source, grab the code and do what you wish with it. From a project roadmap point of view, we need to make it usable before we make it extensible. I see this as a post v1 endeavor.

Moreover, the coupling of the dashboard Aspire package with the Aspire hosting package is noted. Could you shed some light on this decision? Is it possible to decouple them, allowing developers to create alternative dashboards or extend the default one?

This was done for time reasons. I fully expect this to be broken out into various abstractions by the time we ship, see #572.

3-I haven't come across any abstraction packages in Aspire without dependencies. Historically, in .NET Core, the norm has been to provide abstraction packages. Is there a specific reason for Aspire deviating from this approach? I'd appreciate some clarity on this matter.

I assume you mean the Aspire.Hosting packages? See the above. If not, can you clarify?

4-I noticed the existence of the IAnnotation interface but couldn't find detailed documentation explaining its purpose and the impact of adding an annotation to a project. Could you please direct me to relevant documentation or provide more information on this feature?

Annotations are just a typed property bag. There's no documentation for this level of detail in the app model. Source only. I expect this area of the product to change as people build on top.

[Javidleo]

having a handy setup for running distributed applications on development environment with support for observability, health checks, and ... is just fine of course,
but the real need for something like this is in production, configuring All the metrics, logs and ...
is painful. specially when you want to apply them for several applications for production and gather all that data
for such a thing you need to integrate with several technologies like : OTLP for traces, Jeager for exporting, serilog for logging, Graphana for metrics and ...

[DynConcepts]

Javidleo -But also, one must walk before they can run....

[yassinebennani]

Thank you @davidfowl for your quick answer, it's clear, I'll follow #572.

[davidfowl]

Thanks for the feedback and questions! As you dive into the APIs please give us feedback! We know that Aspire has LOTS of useful components that others will want to use. We need to be laser focused to deliver a great v1 experience but we also want to know what you care about (with scenarios of course 😄 )

[yassinebennani]

You're welcome, for sure I will not hesitate to share my feedbacks and contribute if it's possible.

[yassinebennani]

Hi @davidfowl,

As I delve into Aspire, I've been thinking about alternative approaches to configuring our projects. why not just considering a decentralized configuration model, where each project holds its configuration independently. Instead of centralizing all configuration in the AppHost Application, the idea is to allow individual projects to manage their configuration. At the end simply reference projects and call an AddAll method.

My motivation comes from the desire to automate aspects of our microservices solutions, especially when implementing a microservices multi-project template for example. I envision that as a solution grows, team members won't need to repeatedly return to the AppHost application to add project configuration manually. While I understand that Visual Studio aids in adding lines to the AppHost automatically, I believe it could be (maybe) more efficient if the responsibility for service metadata generation becomes part of the microservice's build process it self and also the configuration of the ProjectResource. This way, the microservice owner team can manage this process, and the AppHost application would primarily generate the AddAll extension method.

I understood guys that you have your priorities for the first v1 and the current configuration method is also effective. I'm simply sharing my thoughts, hoping they might be useful in the future.

Additionally, I have some ideas about the initial steps in splitting the Aspire.Hosting package within the existing codebase:

Aspire.Hosting.Abstractions
Aspire.Hosting.ApplicationModel.Abstractions
Aspire.Hosting.ApplicationModel

For other components like RabbitMQ, Redis, etc.:

Aspire.Hosting.ApplicationModel.Redis.Abstractions
Aspire.Hosting.ApplicationModel.Redis

If you're ok with this initial proposal (recognizing that there's more work in this area), I'm ready to initiate the first pull request soon.

Thank you

[DynConcepts]

Interesting alternative... it goes against my typical where no microservice (to the degree possible) knows specifically about others and that the orchestration is external [in Aspire that is AppHost]. Would not putting such things into the project increase coupling?

[we can take off-line: david(dot)corbin(at)live(dot)com]

[davidfowl]

My motivation comes from the desire to automate aspects of our microservices solutions, especially when implementing a microservices multi-project template for example. I envision that as a solution grows, team members won't need to repeatedly return to the AppHost application to add project configuration manually. While I understand that Visual Studio aids in adding lines to the AppHost automatically, I believe it could be (maybe) more efficient if the responsibility for service metadata generation becomes part of the microservice's build process it self and also the configuration of the ProjectResource. This way, the microservice owner team can manage this process, and the AppHost application would primarily generate the AddAll extension method.

I think you should build this in a fork and see what it feels like. It's hard to judge without playing with it.

If you're ok with this initial proposal (recognizing that there's more work in this area), I'm ready to initiate the first pull request soon.

Thanks for your enthusiasm but I don't think we want pull requests refactoring this code as the team is actively working on and is pretty disruptive to shuffle around code like this. It needs to be coordinated.

[davidfowl]

One thing that would be really helpful is to start working on your idea to split up various service dependencies into different projects (with the existing API). That would help inform the feasibility of what you want to do.

[yassinebennani]

Yes you're right, I will try to poc this and share it with you when it's done.

Thank you

[DamianEdwards]

believe it could be (maybe) more efficient if the responsibility for service metadata generation becomes part of the microservice's build process it self and also the configuration of the ProjectResource

We chose the current dependency direction based on the fact that we didn't want service projects to be "special" in any particular Aspire way. They're just regular ASP.NET Core projects. The Aspire Components they reference don't call any Aspire-specific APIs, they just add to existing systems for DI, health checks, telemetry, configuration, etc. Same goes for the ServiceDefaults project. Pushing aspects of the composition configuration onto the resources being composed feels like it would make adoption more complicated than any potential benefit it might add, but as @davidfowl says the only way to know for sure is to try it which is why we invite POCs 😄

[davidfowl]

@yassinebennani Did you ever find the time to build anything?

[davidfowl]

@yassinebennani if you are still interested, I've posted a guide on the aspire resource model https://gist.github.com/davidfowl/b408af870d4b5b54a28bf18bffa127e1