Inconsistency in eShopLite Solutions Across Aspire Repositories

[josephaw1022]

I've noticed a discrepancy in the eShopLite solutions presented in different parts of the Aspire repositories. Specifically, there are two versions of the eShopLite solution, and they appear to be at different stages of development or feature completeness.

1. Main Aspire Repository: The first version of eShopLite is located in the main Aspire repository, under the samples directory. This version seems more comprehensive and feature-rich. It can be found here: Main Aspire eShopLite Sample.

2. Aspire-Samples Repository: The second version is in the Aspire-Samples repository. It's also under a samples directory but appears to be a smaller and less feature-complete version of the eShopLite solution. This can be viewed here: Aspire-Samples eShopLite.

Issue Summary:
There seems to be an inconsistency between these two versions of the eShopLite solution. The version in the main Aspire repo is more developed compared to the one in the Aspire-Samples repo.

[stuartpa]

Agree, please share the roadmap here between these two implementations of eShopLite. My guess in looking at them, is the "aspire-samples" version is more advanced (e.g. works with azd init/up) with a smaller surface area, and over time it will be the surviving version. The version in this repo (aspire), has a larger surface area, but has not been updated to work with azd init/up.

(also while we're on the subject of eShop implementations. Is there a roadmap that includes the gradual maturation of eShopLite to eventually replace the full eShop?)

[josephaw1022]

I've noticed that the Aspire repository contains some unique services in the eShop sample, such as an API Gateway project (found at https://github.com/dotnet/aspire/tree/main/samples/eShopLite/ApiGateway). In addition, one of the projects demonstrates deploying to a local Kubernetes cluster, which is a valuable feature for development and testing purposes. These services and capabilities seem to be exclusive to the Aspire repository and are not present in other related repositories like the eShop sample repository (https://github.com/dotnet/aspire-samples) or the main eShop repository (https://github.com/dotnet/eShop).

Including such practical deployment examples in the main or eshop lite sample repository could provide significant value. While there are various methods to implement and manage deployments, showcasing how to deploy to a local Kubernetes cluster directly within these examples would be highly beneficial. It would give a clearer picture of the capabilities and integrations possible within Aspire, particularly for developers who are exploring or transitioning to this architecture.

Incorporating these unique components, including the API Gateway and the local Kubernetes deployment process, into the other eShop sample repositories would ensure that valuable information and nuanced features are not overlooked.

[DamianEdwards]

The version in the main aspire repo is less a true sample and more a solution that can be used while working on aspire features (hence it being in the main repo) to quickly verify and experience features as they're being worked on. The version in the aspire-samples repo is intended to be a standalone example that can be consumed and reasoned about without any knowledge of the aspire source itself.

If there are features/implementations from one version that you think should be in the other, go ahead and log a specific issue in the relevant repo to suggest it be added.

[stuartpa]

Is there guidance/roadmap on what the goal is for how far the functionality in eShopLite (in aspire-samples) should evolve towards the functionality of the full eShop (https://github.com/dotnet/eShop).

[DamianEdwards]

Is there guidance/roadmap on what the goal is for how far the functionality in eShopLite (in aspire-samples) should evolve towards the functionality of the full eShop (https://github.com/dotnet/eShop).

No, other than to say I don't expect it to grow much beyond what it has now. It's just intended to be a "lighter" version with much less going on but enough to demonstrate a more than just a frontend talking to a backend API with a Redis cache.

[stuartpa]

Ok, thanks @DamianEdwards, this is what I needed know. I'll follow up on where would be the best place to bring in the multi-tenant concept so we can demonstrate Azure Database Fleet Manager (https://aka.ms/azdbfleet). If someone is already looking at multi-tenancy, please let me know.

[danmoseley]

fyi @adityamandaleeka