* Clean up usings and controller attributes
- Removed redundant attributes when the controllers already specifies what the result type is.
- Use StatusCodes instead of HttpStatusCode.
- Clean up namespaces and use type aliases to disambiguate the many DTOs defined.
* Forgot one
* Update src/Services/Webhooks/Webhooks.API/Controllers/WebhooksController.cs
Co-authored-by: Reuben Bond <203839+ReubenBond@users.noreply.github.com>
---------
Co-authored-by: Reuben Bond <203839+ReubenBond@users.noreply.github.com>
According to https://github.com/dotnet/runtime/issues/65396, using a new JsonSerializerOptions every time JsonSerializer is invoked is a suboptimal pattern.
Fix this by caching JsonSerializerOptions instances.
- Removed manual port binding code
- Disable Seq and logstash if config is null
- Disable serilog for now
- Remove IIS from some launch profiles
- Clean up some logging.
* Update jsonpointer version 5.0.0, ansi-html version to 0.0.8 and webpack-dev-server to webpack-dev-server version 3.11.2 was using ansi-html which is depreciated but in latest version 3.11.3 it's changed to ansi-html-community version 0.0.8
* Fix integrity issue in PR #1822
Co-authored-by: Tarun Jain <v-tjain@microsoft.com>
* Seeking feedback: Build and run on .Net 6 preview 6 (#1734)
* Updgrade build and hosting machines to .net6 latest
* Target .net 6
* ILogger is ambiguous?
* More ILogger ambiguity
* Use preview 6... seeing errors in preview 7...
* Of course the SDK version is different :)
* downgrade the last nonworking component
* Only restore the packages we need for the one off service stuck in .net 5
* Downgrade development docker files to use the preview 6 sdk
* Updates `basket-api` to .NET 6 (#1742)
* Use global usings
* Use file-scoped namespaces
* Updates docker images to preview 7
* Created a new migration plan
* Included global usings for identity project
* Updated docker file to preview version to 7
* Updated dockerfiles
* Merged conent from Startup.cs to Program.cs
* Removed Starup.cs
* Removed unnecessary files
* Revert "Removed unnecessary files"
This reverts commit 536bddcd96b54673401cedbe802520dce12b3472.
* Revert "Removed Starup.cs"
This reverts commit 46175d7aa97475d88ec46bce39ed498c7037d924.
* Revert "Merged conent from Startup.cs to Program.cs"
This reverts commit 2766ea86dfef9220fe3f0c27a37a9a6c18153078.
* Removed extra spaces
* Updated basket-api project file
* Update src/Services/Basket/Basket.API/Grpc/BasketService.cs
Co-authored-by: David Pine <david.pine@microsoft.com>
* Apply suggestions from code review
Co-authored-by: David Pine <david.pine@microsoft.com>
* Moved the fully qualified namespace on top
* Updated relevant packages in basket.api project
* Updated relevant packages in identity.api project
Co-authored-by: David Pine <david.pine@microsoft.com>
* Updates all the services to .NET 6.0 (#1770)
* Created global using file for catalog.api
* Moved individual usings statements to globalusing
* Updated catalog.api project
* Fixed local run bug for catalog.api
* Included globalusing for payment.api
* Refactored namespace statement for payment.api
* Moved namespaces to ordering.domain project
* Included globalusing for ordering.domain project
* Included globalusings for ordering.infrastructure project
* Refactored namespaces for ordering.infrastructure project
* Updated relevant packages in ordering.infrastructure project
* Included globalusings for ordering.signalrHub project
* Moved all the namespace to globalusings
* Updated packages in ordering.signalrHub csproj file
* Refactored namespace statements in catalog.api project
* Fixed namespace name in ordering.domain
* Included global usings for ordering.api project
* Moved all usings to globalusing file
* Updated ordering.api csproj project
* Fixed bug in statup.cs
* Updated ordering.unittests.csproj file
* Included globalusings in webhooks.api project
* Moved using statements to globalusing file in webhooks.api
* Included globalusing for web.bff.shoppping aggregator project
* Moved namespaces to globalusing shopping aggregator
* Included globalusing mobile.bff.shoppping project
* Moved namespaces to globalusing file
* Included globalusing for eventbus project
* Moved namespaces to global usings for eventbus
* Included globalusing for EventBusRabbitMQ project
* Moved using statements to EventBusRabbitMQ project
* Included global using in EventBusServiceBus project
* Moved using statements to globalusing for EventBusServiceBus
* Included globalusing file for IntegrationEventLogEF project
* Move using statements to globalusing file
* Updated packages of IntegrationEventLogEF project
* Included globalusing to Devspaces.Support project
* Moved using statements to globalusing Devspaces
* Updated dependent packages for Devspaces.Support.csproj
* Fixed bug in Basket API
* Fixed bug in catalog.api
* Fixed bug Identity.API
* Included globalusing to Basket.UnitTest project
* Moved namespaces to Basket.UnitTest project
* Updated packages of Basket.UnitTest csproj
* Included globalusing for Basket.FunctionalTests project
* Included file-scoped namespaces Basket.FunctionalTests
* Updated packages of Basket.FunctionalTests.csproj file
* Updated catalog unit test project to Net 6.0
* Included global usings for Catalog.FunctionalTests
* Included file-scope namespace catalog.functionaltests
* Updated packages of catalog.functionaltest csproj
* Included MigrateDbContext method in HostExtensions
* Included globalusing for ordering.UnitTests project
* Included file-scope statement for Ordering.UnitTest project
* Included globalusing for Ordering.FunctionalTests
* Included file-scope namespace statement for using
* Updated packages in Ordering.FunctionalTests.csproj
* Apply suggestions from code review
Co-authored-by: David Pine <david.pine@microsoft.com>
* Apply suggestions from code review
Co-authored-by: David Pine <david.pine@microsoft.com>
* Update src/Services/Ordering/Ordering.API/Startup.cs
Co-authored-by: David Pine <david.pine@microsoft.com>
* Update src/Services/Ordering/Ordering.Domain/Events/OrderStatusChangedToPaidDomainEvent.cs
Co-authored-by: David Pine <david.pine@microsoft.com>
* Update src/Services/Ordering/Ordering.SignalrHub/IntegrationEvents/EventHandling/OrderStatusChangedToSubmittedIntegrationEventHandler.cs
Co-authored-by: David Pine <david.pine@microsoft.com>
* Update src/Services/Ordering/Ordering.SignalrHub/IntegrationEvents/Events/OrderStatusChangedToAwaitingValidationIntegrationEvent.cs
Co-authored-by: David Pine <david.pine@microsoft.com>
* Apply suggestions from code review
Co-authored-by: David Pine <david.pine@microsoft.com>
* Apply suggestions from code review
Co-authored-by: David Pine <david.pine@microsoft.com>
Co-authored-by: David Pine <david.pine@microsoft.com>
* Updates WebMVC to .NET 6.0 (#1773)
* Included globalusing WebMVC
* Included file scope namespaces for all files
* Updated dockerfile
* Updated packages to WebMVC
* Fixes few bugs in Net 6.0 service migration (#1774)
* Created global using file for catalog.api
* Moved individual usings statements to globalusing
* Updated catalog.api project
* Fixed local run bug for catalog.api
* Included globalusing for payment.api
* Refactored namespace statement for payment.api
* Moved namespaces to ordering.domain project
* Included globalusing for ordering.domain project
* Included globalusings for ordering.infrastructure project
* Refactored namespaces for ordering.infrastructure project
* Updated relevant packages in ordering.infrastructure project
* Included globalusings for ordering.signalrHub project
* Moved all the namespace to globalusings
* Updated packages in ordering.signalrHub csproj file
* Refactored namespace statements in catalog.api project
* Fixed namespace name in ordering.domain
* Included global usings for ordering.api project
* Moved all usings to globalusing file
* Updated ordering.api csproj project
* Fixed bug in statup.cs
* Updated ordering.unittests.csproj file
* Included globalusings in webhooks.api project
* Moved using statements to globalusing file in webhooks.api
* Included globalusing for web.bff.shoppping aggregator project
* Moved namespaces to globalusing shopping aggregator
* Included globalusing mobile.bff.shoppping project
* Moved namespaces to globalusing file
* Included globalusing for eventbus project
* Moved namespaces to global usings for eventbus
* Included globalusing for EventBusRabbitMQ project
* Moved using statements to EventBusRabbitMQ project
* Included global using in EventBusServiceBus project
* Moved using statements to globalusing for EventBusServiceBus
* Included globalusing file for IntegrationEventLogEF project
* Move using statements to globalusing file
* Updated packages of IntegrationEventLogEF project
* Included globalusing to Devspaces.Support project
* Moved using statements to globalusing Devspaces
* Updated dependent packages for Devspaces.Support.csproj
* Fixed bug in Basket API
* Fixed bug in catalog.api
* Fixed bug Identity.API
* Included globalusing to Basket.UnitTest project
* Moved namespaces to Basket.UnitTest project
* Updated packages of Basket.UnitTest csproj
* Included globalusing for Basket.FunctionalTests project
* Included file-scoped namespaces Basket.FunctionalTests
* Updated packages of Basket.FunctionalTests.csproj file
* Updated catalog unit test project to Net 6.0
* Included global usings for Catalog.FunctionalTests
* Included file-scope namespace catalog.functionaltests
* Updated packages of catalog.functionaltest csproj
* Included MigrateDbContext method in HostExtensions
* Included globalusing for ordering.UnitTests project
* Included file-scope statement for Ordering.UnitTest project
* Included globalusing for Ordering.FunctionalTests
* Included file-scope namespace statement for using
* Updated packages in Ordering.FunctionalTests.csproj
* Apply suggestions from code review
Co-authored-by: David Pine <david.pine@microsoft.com>
* Apply suggestions from code review
Co-authored-by: David Pine <david.pine@microsoft.com>
* Update src/Services/Ordering/Ordering.API/Startup.cs
Co-authored-by: David Pine <david.pine@microsoft.com>
* Update src/Services/Ordering/Ordering.Domain/Events/OrderStatusChangedToPaidDomainEvent.cs
Co-authored-by: David Pine <david.pine@microsoft.com>
* Update src/Services/Ordering/Ordering.SignalrHub/IntegrationEvents/EventHandling/OrderStatusChangedToSubmittedIntegrationEventHandler.cs
Co-authored-by: David Pine <david.pine@microsoft.com>
* Update src/Services/Ordering/Ordering.SignalrHub/IntegrationEvents/Events/OrderStatusChangedToAwaitingValidationIntegrationEvent.cs
Co-authored-by: David Pine <david.pine@microsoft.com>
* Apply suggestions from code review
Co-authored-by: David Pine <david.pine@microsoft.com>
* Apply suggestions from code review
Co-authored-by: David Pine <david.pine@microsoft.com>
* Fixed bugs in Mobile.BFF.Shopping project
* Fixed bugs in Web.Bff.Shopping aggregator project
* Fixed bugs in EventBusServiceBus project
* Fixed bug in Mobile.Bff.Shopping project
Co-authored-by: David Pine <david.pine@microsoft.com>
* Updates webhook client project to .NET 6.0 (#1777)
* Included globalusing file for webhookclient
* Included file scope namespaces for Webhookclient
* Updated packages in WebHookClient project
* Updates webspa project to Net 6.0 (#1778)
* Included globalusing in webspa project
* Included file scoped namespace for webspa project
* Updated packages in WebSPA project
* Updates the Application.FunctionalTests project to .NET 6.0 (#1781)
* Included globalusing in Application.FunctionalTests project
* Included file scoped namespace
* Renamed Azure.Messaging.ServiceBus namespace
* Updates .NET version of Dockerfile to 6.0 (#1785)
* Updatated package versions to RC2
* Updated package versions to RC2
* Updated Dockerfiles to .NET 6 RC2
* Changed docker file tag to 6.0
* Updated Program class
* Updated globalusing file
* Removed preview tag reference from Dockerfile.develop file
* Updated dotnet version to .NET 6.0
* Updated all packages to the .NET 6.0
* Removed RC tag from dockerfile
* Fixed bundleconfig json
* Updated readme files
* Fixed ingress yaml indentation
* Included globalusing for WebStatus project
* Updated WebStatus project to .NET 6.0
* Included scoped namespace
* Updated Dockerfile of WebStatus to .NET 6.0
Co-authored-by: Josh Coleman <83677148+JcolemanNR@users.noreply.github.com>
Co-authored-by: David Pine <david.pine@microsoft.com>
* updated CardType and Enumeration classes
* Update per IEvangelist's suggestion
* Update src/Services/Ordering/Ordering.Domain/SeedWork/Enumeration.cs
Co-authored-by: David Pine <david.pine@microsoft.com>
Co-authored-by: Sumit Ghosh <sumit.ghosh@neudesic.com>
Co-authored-by: David Pine <david.pine@microsoft.com>
* Removed Unused Using and Reorganized the Using
* Removed unused using, Reorganized using, moved the class to separate file, removed commented code in Catalog.API
* Revert "Removed unused using, Reorganized using, moved the class to separate file, removed commented code in Catalog.API"
This reverts commit 34241c430619b3b0bbeaabafa44c078c859237c4.
* Removed unused using and reorganized the using inside "Services" folder
* Removed Unused using and reoganized the using
* Refactor Webhooks.API
* Removed unused using and reorganized using inside Catalog.API
* Refactoring
* Removed unsed using
* Added line break just to differentiate between the messages
* Removed unused usings
* Simple Refactoring
* Removed Unused Using and Reorganized the Using
* Removed unused using, Reorganized using, moved the class to separate file, removed commented code in Catalog.API
* Revert "Removed unused using, Reorganized using, moved the class to separate file, removed commented code in Catalog.API"
This reverts commit 34241c430619b3b0bbeaabafa44c078c859237c4.
* Removed unused using and reorganized the using inside "Services" folder
* Removed Unused using and reoganized the using
* Refactor Webhooks.API
* Removed unused using and reorganized using inside Catalog.API
* Refactoring
* Removed unsed using
* Added line break just to differentiate between the messages
* Removed Unused Using and Reorganized the Using
* Removed unused using, Reorganized using, moved the class to separate file, removed commented code in Catalog.API
* Revert "Removed unused using, Reorganized using, moved the class to separate file, removed commented code in Catalog.API"
This reverts commit 34241c430619b3b0bbeaabafa44c078c859237c4.
* Removed unused using and reorganized the using inside "Services" folder
* Removed Unused using and reoganized the using
* Refactor Webhooks.API
* Removed unused using and reorganized using inside Catalog.API
* #1403 removed duplicate Key SubscriptionClientName
Removed duplicate key SubscriptionClientName from Tests/Services/Application.FunctionalTests/Services/Marketing/appsettings.json and sorted its content in asc order.
* #1404 Added app.UseAuthorization() call
Added app.UseAuthorization() call to BasketTestsStartup, LocationsTestsStartup, and MarketingTestsStartup to fix failed unit tests IntegrationEventsScenarios.Post_update_product_price_and_catalog_and_basket_list_modified and MarketingScenarios.Set_new_user_location_and_get_location_campaign_by_user_id (see #1404)
* Fix issue with Status set when items list is empty
* Change method Count() call to Count property
Co-authored-by: Dmytro Hridin <v-dmytro.hridin@lionbridge.com>
* add trigger to include pipelines
* Update build/azure-devops/webhooks-client/azure-pipelines.yml
Co-Authored-By: Miguel Veloso <mvelosop@gmail.com>
Co-authored-by: Miguel Veloso <mvelosop@gmail.com>
This repo is a reference and learning resource and everyone is invited to contribute, however not all PRs will be accepted into the main branch (**`dev`**).
There's a general development strategy that's driven by @CESARDELATORRE, who chooses, or defines criteria for choosing, the issues to include in the codebase, given a bunch of constraints and other guidelines.
There's a general development strategy that's driven by @CESARDELATORRE/@nishanil, who chooses, or defines criteria for choosing, the issues to include in the codebase, given a bunch of constraints and other guidelines.
However you can always get in touch with him, if you want to implement some general-interest feature in your repo and have it referenced from the [documentation](https://docs.microsoft.com/dotnet/standard/microservices-architecture/) or the [Microservices eBook](https://aka.ms/microservicesebook/).
@ -47,15 +47,14 @@ All contributions must be submitted as a [Pull Request (PR)](https://help.github
The main branches are **`dev`** and **`master`**:
- **`dev`**: Contains the latest code **and it is the branch actively developed**.
**All PRs must be against `dev` branch to be considered**. This branch is developed using .NET Core 2.x
**All PRs must be against `dev` branch to be considered**. This branch is developed using `.NET 7`
- **`master`**: Synced from time to time from **`dev`**. It contains "stable" code.
(**Keep in mind "stable" does not mean PRODUCTION-READY!**)
- **`main`**: Synced from time to time from **`dev`**. It contains "stable" code.This branch contains changes specific to `.NET Core 3.1` (**Keep in mind "stable" does not mean PRODUCTION-READY!**)
- Any other branch is considered temporary and could be deleted at any time. Do not submit any PR to them!
## DISCLAIMER - This is not a PRODUCTION-READY TEMPLATE for microservices
eShopOnContainers is a reference application to **showcase architectural patterns** for developing microservices applications on .NET Core. **IT IS NOT A PRODUCTION-READY TEMPLATE** to start real-world application. In fact, the application is in a **permanent beta state**, as it’s also used to test new potentially interesting technologies as they show up.
eShopOnContainers is a reference application to **showcase architectural patterns** for developing microservices applications on .NET 5. **IT IS NOT A PRODUCTION-READY TEMPLATE** to start real-world application. In fact, the application is in a **permanent beta state**, as it’s also used to test new potentially interesting technologies as they show up.
Since this is a learning resource, some design decisions have favored simplicity to convey a pattern, over production-grade robustness.
# eShopOnContainers - Microservices Architecture and Containers based Reference Application (**BETA state** - Visual Studio and CLI environments compatible)
Sample .NET Core reference application, powered by Microsoft, based on a simplified microservices architecture and Docker containers.
## Linux Build Status for 'dev' branch
## SPA Application (Angular)
Dev branch contains the latest "stable" code, and their images are tagged with `:dev` in our [Docker Hub](https://cloud.docker.com/u/eshop/repository/list):

| Basket API | Catalog API | Identity API | Location API |
_**Dev** branch contains the latest **beta** code and their images are tagged with `:linux-dev` in our [Docker Hub](https://hub.docker.com/u/eshop)_
## Getting Started
eShopOnContainers is provided in "two flavours":
Make sure you have [installed](https://docs.docker.com/docker-for-windows/install/) and [configured](https://github.com/dotnet-architecture/eShopOnContainers/wiki/Windows-setup#configure-docker) docker in your environment. After that, you can run the below commands from the **/src/** directory and get started with the `eShopOnContainers` immediately.
* Basic scenario: Can be run locally using docker compose, and also deployed to a local Kubernetes cluster
* Production scenario: Can only be deployed on a Kubernetes cluster (local or in the cloud like AKS), and enable production features like the use of a Service Mesh.
```powershell
docker-compose build
docker-compose up
```
You should be able to browse different components of the application by using the below URLs :
```
Web Status : http://host.docker.internal:5107/
Web MVC : http://host.docker.internal:5100/
Web SPA : http://host.docker.internal:5104/
```
>Note: If you are running this application in macOS then use `docker.for.mac.localhost` as DNS name in `.env` file and the above URLs instead of `host.docker.internal`.
Below are the other avenues to setup *eShopOnContainers*.
### Basic scenario
You can run eShop locally:
The basic scenario can be run locally using docker-compose, and also deployed to a local Kubernetes cluster. Refer to these Wiki pages to Get Started:
The Advanced scenario can be run only in a Kubernetes cluster. Currently this scenario is the same as basic scenario with the following differences:
The Advanced scenario can be run only in a Kubernetes cluster. Currently, this scenario is the same as a basic scenario with the following differences:
* Use of a Service Mesh for Resiliency
- [Deploy to AKS with a Service Mesh for resiliency](https://github.com/dotnet-architecture/eShopOnContainers/wiki/Deploy-to-Azure-Kubernetes-Service-(AKS))
In the future, more features will be implemented in the advanced scenario.
In the future more features will be implemented in the advanced scenario.
## IMPORTANT NOTES!
**You can use either the latest version of Visual Studio or simply Docker CLI and .NET CLI for Windows, Mac and Linux**.
**You can use either the latest version of Visual Studio or simply Docker CLI and .NET CLI for Windows, Mac, and Linux**.
**Note for Pull Requests (PRs)**: We accept pull request from the community. When doing it, please do it onto the **DEV branch** which is the consolidated work-in-progress branch. Do not request it onto Master branch, if possible.
**Note for Pull Requests (PRs)**: We accept pull requests from the community. When doing it, please do it onto the **DEV branch** which is the consolidated work-in-progress branch. Do not request it onto **main** branch.
**NEWS / ANNOUNCEMENTS**
Do you want to be up-to-date on .NET Architecture guidance and reference apps like eShopOnContainers? --> Subscribe by "WATCHING" this new GitHub repo: https://github.com/dotnet-architecture/News
## Updated for .NET Core 3.0
eShopOnContainers is updated to .NET Core 3.0 "wave" of technologies. Not just compilation but also new recommended code in EF Core, ASP.NET Core, and other new related versions.
## Updated for .NET 7
The **dockerfiles** in the solution have also been updated and now support [**Docker Multi-Stage**](https://blogs.msdn.microsoft.com/stevelasker/2017/09/11/net-and-multistage-dockerfiles/) since mid-December 2017.
eShopOnContainers is updated to .NET 7 "wave" of technologies. Not just compilation but also new recommended code in EF Core, ASP.NET Core, and other new related versions with several significant changes.
**See more details in the [Release notes](https://github.com/dotnet-architecture/eShopOnContainers/wiki/Release-notes) wiki page**.
>**PLEASE** Read our [branch guide](./branch-guide.md) to know about our branching policy
>
> ### DISCLAIMER
>
> **IMPORTANT:** The current state of this sample application is **BETA**, because we are constantly evolving towards newly released technologies. Therefore, many areas could be improved and change significantly while refactoring the current code and implementing new features. Feedback with improvements and pull requests from the community will be highly appreciated and accepted.
>
> This reference application proposes a simplified microservice oriented architecture implementation to introduce technologies like .NET Core with Docker containers through a comprehensive application. The chosen domain is eShop/eCommerce but simply because it is a well-known domain by most people/developers.
However, this sample application should not be considered as an "eCommerce reference model" at all. The implemented business domain might not be ideal from an eCommerce business point of view. It is neither trying to solve all the problems in a large, scalable and mission-critical distributed system. It is just a bootstrap for developers to easily get started in the world of Docker containers and microservices with .NET Core.
> <p>For example, the next step after running the solution in the local dev PC and understanding Docker containers and microservices development with .NET Core, is to select a microservice cluster/orchestrator like Kubernetes in Azure (AKS) or Azure Service Fabric, both environments tested and supported by this solution.
> Additional steps would be to move your databases to HA cloud services (like Azure SQL Database) or switch your EventBus to use Azure Service Bus (instead of bare-bone RabbitMQ) or any other production-ready Service Bus in the market.
> Read the planned <ahref='https://github.com/dotnet-architecture/eShopOnContainers/wiki/Roadmap'>Roadmap</a> within the Wiki for further info about possible new implementations and provide feedback at the <ahref='https://github.com/dotnet/eShopOnContainers/issues'>ISSUES section</a> if you'd like to see any specific scenario implemented or improved. Also, feel free to discuss on any current issue.
### Architecture overview
This reference application is cross-platform at the server and client side, thanks to .NET Core services capable of running on Linux or Windows containers depending on your Docker host, and to Xamarin for mobile apps running on Android, iOS or Windows/UWP plus any browser for the client web apps.
The architecture proposes a microservice oriented architecture implementation with multiple autonomous microservices (each one owning its own data/db) and implementing different approaches within each microservice (simple CRUD vs. DDD/CQRS patterns) using Http as the communication protocol between the client apps and the microservices and supports asynchronous communication for data updates propagation across multiple services based on Integration Events and an Event Bus (a light message broker, to choose between RabbitMQ or Azure Service Bus, underneath) plus other features defined at the <ahref='https://github.com/dotnet-architecture/eShopOnContainers/wiki/Roadmap'>roadmap</a>.
> ### Important Note on API Gateways and published APIs
> Since April 2018, we have introduced the implementation of the [API Gateway pattern](http://microservices.io/patterns/apigateway.html) and [Backend-For-Front-End (BFF) pattern](https://samnewman.io/patterns/architectural/bff/) in eShopOnContainers architecture, so you can filter and publish simplified APIs and URIs and apply additional security in that tier while hiding/securing the internal microservices to the client apps or outside consumers. These sample API Gateways in eShopOnContainers are based on [Ocelot](https://github.com/ThreeMammals/Ocelot), an OSS lightweight API Gateway solution explained [here](http://threemammals.com/ocelot). The deployed API Gateways are autonomous and can be deployed as your own custom microservices/containers, as it is currently done in eShopOnContainers, so you can test it even in a simple development environment with just Docker engine or deploy it into orchestrators like Kubernetes in AKS or Service Fabric.
This reference application is cross-platform at the server and client-side, thanks to .NET 7 services capable of running on Linux or Windows containers depending on your Docker host, and to Xamarin for mobile apps running on Android, iOS, or Windows/UWP plus any browser for the client web apps.
The architecture proposes a microservice oriented architecture implementation with multiple autonomous microservices (each one owning its own data/db) and implementing different approaches within each microservice (simple CRUD vs. DDD/CQRS patterns) using HTTP as the communication protocol between the client apps and the microservices and supports asynchronous communication for data updates propagation across multiple services based on Integration Events and an Event Bus (a light message broker, to choose between RabbitMQ or Azure Service Bus, underneath) plus other features defined at the [roadmap](https://github.com/dotnet-architecture/eShopOnContainers/wiki/Roadmap).
> For your production-ready architecture you can either keep using [Ocelot](https://github.com/ThreeMammals/Ocelot) which is simple and easy to use and used in production by significant companies or if you need further functionality and a much richer set of features suitable for commercial APIs, you can also substitute those API Gateways and use [Azure API Management](https://azure.microsoft.com/en-us/services/api-management/) or any other commercial API Gateway, as shown in the following image.
> The sample code in this repo is NOT making use of Azure API Management in order to be able to provide an "F5 experience" in Visual Studio (or CLI) of the sample with no up-front dependencies in Azure. But you could evaluate API Gateways alternatives when building for production.
> ### Internal architecture and design of the microservices
> The microservices are different in type, meaning different internal architecture pattern approaches depending on its purpose, as shown in the image below.
> ### Important Note on Database Servers/Containers
> In this solution's current configuration for a development environment, the SQL databases are automatically deployed with sample data into a single SQL Server container (a single shared Docker container for SQL databases) so the whole solution can be up and running without any dependency to any cloud or a specific server. Each database could also be deployed as a single Docker container, but then you'd need more than 8GB of RAM assigned to Docker in your development machine in order to be able to run 3 SQL Server Docker containers in your Docker Linux host in "Docker for Windows" or "Docker for Mac" development environments.
> <p> A similar case is defined in regard to Redis cache running as a container for the development environment. Or a No-SQL database (MongoDB) running as a container.
> <p> However, in a real production environment it is recommended to have your databases (SQL Server, Redis, and the NO-SQL database, in this case) in HA (High Available) services like Azure SQL Database, Redis as a service and Azure CosmosDB instead the MongoDB container (as both systems share the same access protocol). If you want to change to a production configuration, you'll just need to change the connection strings once you have set up the servers in an HA cloud or on-premises.
> ### Important Note on EventBus
> In this solution's current EventBus is a simplified implementation, mainly used for learning purposes (development and testing), so it doesn't handle all production scenarios, most notably on error handling. <p>
> The following forks provide production environment level implementation examples with eShopOnContainers :
> * Implementation with [NServiceBus](https://github.com/Particular/NServiceBus) : https://github.com/Particular/eShopOnContainers
> * Implementation with [CAP](https://github.com/dotnetcore/CAP) : https://github.com/yang-xiaodong/eShopOnContainers


## Related documentation and guidance
While developing this reference application, we've been creating a reference <b>Guide/eBook</b> focusing on <b>architecting and developing containerized and microservice based .NET Applications</b> (download link available below) which explains in detail how to develop this kind of architectural style (microservices, Docker containers, Domain-Driven Design for certain microservices) plus other simpler architectural styles, like monolithic apps that can also live as Docker containers.
<p>
You can find the related reference **Guide/eBook** focusing on **architecting and developing containerized and microservice-based .NET Applications** (download link available below) which explains in detail how to develop this kind of architectural style (microservices, Docker containers, Domain-Driven Design for certain microservices) plus other simpler architectural styles, like monolithic apps that can also live as Docker containers.
There are also additional eBooks focusing on Containers/Docker lifecycle (DevOps, CI/CD, etc.) with Microsoft Tools, already published plus an additional eBook focusing on Enterprise Apps Patterns with Xamarin.Forms.
You can download them and start reviewing these Guides/eBooks here:
Download in other formats (**eReaders** like **MOBI**, **EPUB**) and other eBooks at the [.NET Architecture center](http://dot.net/architecture).
For more free e-Books check out [.NET Architecture center](https://dot.net/architecture). If you have an e-book feedback, let us know by creating a new issue here: <https://github.com/dotnet-architecture/ebooks/issues>
Send feedback to [dotnet-architecture-ebooks-feedback@service.microsoft.com](dotnet-architecture-ebooks-feedback@service.microsoft.com)
## Are you new to **microservices** and **cloud-native development**?
Take a look at the free course [Create and deploy a cloud-native ASP.NET Core microservice](https://docs.microsoft.com/en-us/learn/modules/microservices-aspnet-core/) on MS Learn. This module explains microservices concepts, cloud-native technologies, and reduces the friction in getting started with `eShopOnContainers`.
However, we encourage you to download and review the [Architecting and Developing Microservices eBook](https://aka.ms/microservicesebook) because the architectural styles and architectural patterns and technologies explained in the guide are using this reference application when explaining many pattern implementations, so you'll understand the context, design and decisions taken in the current architecture and internal designs much better.
## Read further
## Overview of the application code
In this repo you can find a sample reference application that will help you to understand how to implement a microservice architecture based application using <b>.NET Core</b> and <b>Docker</b>.
The example business domain or scenario is based on an eShop or eCommerce which is implemented as a multi-container application. Each container is a microservice deployment (like the basket-microservice, catalog-microservice, ordering-microservice and the identity-microservice) which is developed using ASP.NET Core running on .NET Core so they can run either on Linux Containers and Windows Containers.
The screenshot below shows the VS Solution structure for those microservices/containers and client apps.
- (*Recommended when getting started*) Open <b>eShopOnContainers-ServicesAndWebApps.sln</b> for a solution containing just the server-side projects related to the microservices and web applications.
- Open <b>eShopOnContainers-MobileApps.sln</b> for a solution containing just the client mobile app projects (Xamarin mobile apps only). It works independently based on mocks, too.
- Open <b>eShopOnContainers.sln</b> for a solution containing all the projects (All client apps and services).
<imgsrc="img/vs-solution-structure.png">
Finally, those microservices are consumed by multiple client web and mobile apps, as described below.
<br>
<b>*MVC Application (ASP.NET Core)*</b>: It's an MVC application where you can find interesting scenarios on how to consume HTTP-based microservices from C# running in the server side, as it is a typical ASP.NET Core MVC application. Since it is a server-side application, access to other containers/microservices is done within the internal Docker Host network with its internal name resolution.
<imgsrc="img/eshop-webmvc-app-screenshot.png">
<br>
<b>*SPA (Single Page Application)*</b>: Providing similar "eShop business functionality" but developed with Angular, Typescript and slightly using ASP.NET Core MVC. This is another approach for client web applications to be used when you want to have a more modern client behavior which is not behaving with the typical browser round-trip on every action but behaving like a Single-Page-Application which is more similar to a desktop app usage experience. The consumption of the HTTP-based microservices is done from TypeScript/JavaScript in the client browser, so the client calls to the microservices come from out of the Docker Host internal network (Like from your network or even from the Internet).
<imgsrc="img/eshop-webspa-app-screenshot.png">
<br>
<b>*Xamarin Mobile App (For iOS, Android and Windows/UWP)*</b>: It is a client mobile app supporting the most common mobile OS platforms (iOS, Android and Windows/UWP). In this case, the consumption of the microservices is done from C# but running on the client devices, so out of the Docker Host internal network (Like from your network or even the Internet).
<imgsrc="img/xamarin-mobile-App.png">
## Setting up your development environment for eShopOnContainers
See at the [Wiki](https://github.com/dotnet-architecture/eShopOnContainers/wiki) the posts on setup/instructions about how to deploy to Kubernetes or Service Fabric in Azure (although you could also deploy to any other cloud or on-premises).
- [Explore the application](https://github.com/dotnet-architecture/eShopOnContainers/wiki/Explore-the-application)
- [Explore the code](https://github.com/dotnet-architecture/eShopOnContainers/wiki/Explore-the-code)
## Sending feedback and pull requests
As mentioned, we'd appreciate your feedback, improvements and ideas.
You can create new issues at the issues section, do pull requests and/or send emails to **eshop_feedback@service.microsoft.com**
Read the planned [Roadmap](https://github.com/dotnet-architecture/eShopOnContainers/wiki/Roadmap) within the Wiki for further info about possible new implementations and provide feedback at the [ISSUES section](https://github.com/dotnet/eShopOnContainers/issues) if you'd like to see any specific scenario implemented or improved. Also, feel free to discuss on any current issue.
- `dev`: Contains the latest code **and it is the branch actively developed**. Note that **all PRs must be against `dev` branch to be considered**. This branch is developed using .NET Core 2.0
- `master`: Synced time to time from dev. It contains "stable" code, although not the latest one. We plan to do periodic merges from `dev` to `master`, but we are not doing it right now.
- `dev`: Contains the latest code **and it is the branch actively developed**. Note that **all PRs must be against the `dev` branch to be considered**. This branch is developed using `.NET 7`
- `release/net-6`: Contains the code changes specific to the `.NET 6`
- `release/net-5`: Contains the code changes specific to the `.NET 5`
- `release/net-3.1.1`: Contains the code changes specific to the `.NET 3.1`
Any other branch is considered temporary and could be deleted at any time. Do not do any PR to them!
> [!DISCLAIMER]: The `main` branch contains the old code base and will get obsolete in the future. So it's recommended to refer to different [tags](https://github.com/dotnet-architecture/eShopOnContainers/tags) to avoid any confusion.
Any other branch is considered temporary and could be deleted at any time. Do not submit any PR against them!
This folder contains the Azure Devops build definitions in YAML format. Each folder contains one `azure-pipelines.yml` that contains the build definition for one microservice (usually a Docker image, but some microservices generates more than one Docker image).
For more information about YAML builds read the [Azure DevOps documentation](https://docs.microsoft.com/en-us/azure/devops/pipelines/get-started-yaml?view=azure-devops).
The ARM template `deploystorage.json` and its parameter file (`deploystorage.parameters.json`) are used to deploy following resources:
1. One Storage Account
2. One CDN profile
3. One Endpoint
## Editing deploystorage.parameters.json file
You can edit the `deploystorage.parameters.json` file to set your values, but is not needed. The only parameters that can
be set are:
1. `marketingstorage` is a string that is used to create the storage account name. ARM script creates unique values by appending a unique string to this parameter value, so you can leave the default value.
2. `profileName` is a string that is used to create the CDN profile name.
3. `endpointName` is a string that is used to create the storage endpoint name. ARM script creates unique values by appending a unique string to this parameter value, so you can leave the default value.
## Deploy the template
Once parameter file is edited you can deploy it using [create-resources script](../../readme.md).
i. e. if you are in windows, to deploy a Storage account in a new resourcegroup located in westus, go to `deploy\az` folder and type:
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.