Hello everyone!
We are the .NET developers community from Raiffeisenbank, and we want to share our set of infrastructure libraries on .NET Core for quickly creating microservices within a unified ecosystem. We've open-sourced it!
A Bit of History
At one time, we had a large monolithic project that gradually transformed into a set of microservices (you can read about the specifics of this process in ). During this process, we faced the challenge that when creating new microservices, we often had to copy various infrastructure solutions—like logging configurations, working with databases, WCF, etc. One team worked on this project, and everyone was already accustomed to a certain established approach to working with the infrastructure. Therefore, we separated the common code into a dedicated repository, wrapped the collected libraries into Nuget packages, and placed them in our internal Nuget repository.
As time went on, the project gradually fragmented, and there was a desire to create new client-side modules using a modern JS framework and deploy them in the browser. We began transitioning from WCF/SOAP to REST/HTTP, which required new libraries for quickly launching services based on AspNet WebApi. The first version on .Net Framework 4.5 was developed almost on the fly by our architect in his spare time, but it already out-of-the-box allowed launching a service with authorization (NTLM), logging, Swagger, IoC/DI based on Castle Windsor, and configured HTTP clients that propagated various headers for end-to-end logging throughout the project. All of this could be further configured directly in the service configuration file.
However, not everything was smooth: this library turned out to be incredibly inflexible regarding the introduction of new modules. For instance, if a specific middleware needed to be added, a new assembly had to be created, inheriting from the base class that launched the service, which was quite inconvenient. Fortunately, such cases were not very frequent.
The era of Docker and Kubernetes
The time has come when the wave of Docker and Kubernetes has also reached us, which we've been closely observing: it was a great opportunity to move forward with technology in .Net Core. This means we need new infrastructure to launch services: some libraries have transitioned from .Net Framework to .Net Standard and .Net Core almost unchanged, while others have seen slight improvements. However, our main goal was to redesign the functionality related to launching services on AspNet Core.
The first step was to consider a concept that would eliminate the main drawback of the previous version: the lack of flexibility. Therefore, it was decided to make the entire library system as independent and modular as possible, assembling the necessary services based on functionality like building blocks.
The main objective is to create a unified approach that describes how to interact with databases, buses, and other services. We aimed for integrations to be quick and painless, allowing developers to focus on writing business logic rather than infrastructure – it's already ready. A shared repository helps enhance the collaboration experience within teams: when very similar internal infrastructures are used, it's easier to get involved in another team's development process and exchange expertise.
And why do we need Open Source?
We want to demonstrate the maturity of our expertise and receive quality feedback: an outsider can bring something new. We're also interested in the development of practices related to microservices and DDD on .NET in the industry; perhaps someone would want to adopt specific parts of the framework.
Actually, ViennaNET
Now let's take a closer look at everything. .
ViennaNET.WebApi.*
This set of libraries consists of the ‘root’ ViennaNET.WebApi, which contains the CompanyHostBuilder class, and a series of configurators ViennaNET.WebApi.Configurators.*, each of which allows adding and configuring specific functionality in the created service. Among the configurators, you'll find connections for logging, diagnostics, types of authentication and authorization, Swagger, etc.
ViennaNET.WebApi.Runners.* includes pre-configured service builders. These packages eliminate the need to remember which configurators to connect each time a new service is created. They do not restrict the functionality of the service builder in any way.
ViennaNET.Mediator.*
Libraries that enable the creation of an internal mediator bus for commands and queries within a service. This approach reduces the number of DI injections to just one, for example, in controllers. As a result, various decorators can be added to the requests, standardizing their processing and reducing code volume.
ViennaNET.Validation
An assembly that contains a set of classes for creating validation rules and sequences derived from them. It's very convenient for implementing domain validation, as it allows describing each business condition as a simple and separate rule.
ViennaNET.Redis
A library with wrappers for convenient interaction with Redis as an in-memory cache.
ViennaNET.Specifications
An assembly containing classes that implement the 'Specification' pattern.
This is far from all that we have in our set. You can check the rest out . The release of our libraries for working with databases as OpenSource is planned soon.
Thank you for your attention, we look forward to your comments and pull requests.
Source: habr.com
