Reduce friction in the Web/Worker/Database on Azure Container Apps scenario

[bradygaster]

[This issue was copied from the planning repo]

Establish baseline effort score for .NET 6 ASP.NET Core customers to create a Worker/Web app that makes use of 2 different Azure messaging services when wired up with Visual Studio Connected Services for a specific, opinionated scenario. We'll first tackle this scenario with Azure Storage Queues, but could roll in Event Grid or other providers if time permits.

The app should consist of the following components:

• [ ] A minimal API that drops messages it receives into an Azure Storage Queue for asynchronous processing by the worker service
• [ ] A front-end ASP.NET Core app providing the user interface to the API
• [ ] A Worker Service project that runs as a queue-watcher, processing incoming messages and saving them to a SQL DB using Entity Framework Core
• [ ] A SQL database storing the data permanently
• [ ] An Azure Storage Queue receiving the API's posts
• [ ] Application Insights telemetry so the customer can see an Application Map of the entire flow of traffic at the end (this is the "visual goal" for the experience)
• [ ] Ideally we use service authentication and not connection strings in this e2e

We'll provide customers/tester the end-to-end and gain insight into the slow parts, complex parts, and gain insight into how the experience could be improved upon.

We'll also provide our testing team the end-to-end as a scenario test they can run on intervals so we can keep tabs on how changes in the APIs and SDKs impact the experience and resources available for customers trying to achieve it.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s). If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s). If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.