EPIC: eShop Modernization/Refresh
adityamandaleeka opened this issue · comments
Creating a top-level issue for us to track the ongoing work to modernize/refresh eShop.
- #2064
- #2069
- #2076
- #2077
- #2093
- #2094
- #2095
- Remove superfluous
UseDeveloperExceptionPagecalls (it's the default) - Fix DataProtection issues by configuring a data protection provider
- Replace Serilog with Microsoft.Extensions.Logging.Console
- Use
ILogger<T>instead of injectingILoggerFactory - Replace Autofac with simple Microsoft.Extensions.DependencyInjection usage
- #2108
- Migrate from ad-hoc
IConfigurationusage to strongly typed Options - Deduplicate use of gRPC and HTTP by using gRPC only for internal-facing microservices
- Migrate to .NET container build (when we can support the .NET container build + docker compose scenario) and delete Dockerfiles
cc: @erjain @ReubenBond
EDIT: Merged into top comment
* [ ] Migrate from ad-hoc `IConfiguration` usage to strongly typed Options * [ ] Replace Autofac with simple Microsoft.Extensions.DependencyInjection usage
Why would you replace Autofac with something that has fewer features?
Also regarding IOptions be sure to read this first: https://www.dabrowski.space/posts/asp.net-options-why-you-should-not-use-it/
EDIT: Merged into top comment
* [ ] Use `ILogger` instead of injecting `ILoggerFactory`. Example: https://github.com/dotnet-architecture/eShopOnContainers/blob/0740fd42b12cbcf2e7ee0b69585bf01312adeddd/src/Services/Ordering/Ordering.API/Application/DomainEventHandlers/OrderStockConfirmed/OrderStatusChangedToStockConfirmedDomainEventHandler.cs#L14Why would you replace Autofac with something that has fewer features?
Autofac is undeniably more powerful and feature-rich. For the purposes of this project, however, I would rather we be explicit about what types in the application are services for DI and what interfaces they satisfy. It certainly should not be taken as endorsement of MEDI over Autofac.
Also regarding IOptions be sure to read this first: https://www.dabrowski.space/posts/asp.net-options-why-you-should-not-use-it/
The issue today is that stringly IConfiguration access is sprinkled around the codebase. The IOptions<T> type isn't supposed to be an aspiring GoF/OOP pattern, it's just a practical mechanism which works with C#'s type system and DI to attach certain functionality to a category of types. Specifically, configuration types and the functionality includes binding, programmatic configuration, validation, and post-config. In this case, the intention is to guide developers into a pattern which we consider to be a good pattern.
EDIT: Merged into top comment
* [ ] Fix DataProtection issues by configuring a data protection providerMany of these are addressed in #2107
Is see that src/Services/Ordering/Ordering.API/Infrastructure/Filters/HttpGlobalExceptionFilter.cs (and from other services) is deleted. What is the reason for this? How are validation errors from in example FluentValidation handled. But also xxxDomainExceptions?
We’re going to bring back some of it and use problem details instead of the custom format.
Really great to see the plans to modernize eShopOnContainers - I have used it for a number of demos and developer training over the years.
One thing I noticed is that it seems like the latest version is no longer logging to Seq (presumably because of the move away from Serilog). Will this be restored or are there plans to send the logs elsewhere?
I suggest to also update the Wiki, as the architecture documentation is quite out of the date and seems to relate mostly to the .NET 5 rewrite.
To pick on the previous comment as an example, Serilog alongside Seq is still documented as the current logging approach.
Are we also implementing OpenTelemetry with this ongoing task to modernize the eshop app?
If not, then can we add it?
@adityamandaleeka - can this issue be closed now that we have https://github.com/dotnet/eShop?