In my original Polly article, I introduced Polly as a robust resilience framework for handling transient faults and service failures. At the time, Polly was entirely community-driven and required manual configuration within each application. Fast forward five years, and Microsoft has officially embraced the concepts introduced by Polly, incorporating them directly into the .NET framework with a suite of first-party resilience libraries.
Continue reading Advanced Fault Tolerance in .NET 8 Using Microsoft’s Resilience FrameworkCategory Archives: Design Patterns
Fault tolerance using Polly
What is a Resilience Framework?
Polly is classed as a resilience framework. A resilience framework is a set of libraries that help an application to recover from transient or more extended failures in services or infrastructure upon which it depends. When recovery is not possible, the resilience framework will facilitate graceful degradation of your application.
Polly has been around for many years and has been tried and tested in many applications
http://www.thepollyproject.org/
The source code for Polly can be found on GitHub here:
https://github.com/App-vNext/Polly
Continue reading Fault tolerance using Polly
Claim-Check Pattern
I’ve been using an Event Bus for some time now in the designs of a system, for reason of performance and scalability. There is also an issue with the message size. But it would be best if you were using the Event Bus as a messaging system, not a data transport mechanism.
There is a solution to this, and it is the claim-check pattern.
Continue reading Claim-Check Pattern
Multi-Tenancy
What Is Multi-Tenancy?
“Software Multitenancy refers to a software architecture in which a single instance of a software runs on a server and serves multiple tenants. A tenant is a group of users who share common access with specific privileges to the software instance. With a multitenant architecture, a software application is designed to provide every tenant a dedicated share of the instance including its data, configuration, user management, tenant individual functionality and non-functional properties. Multitenancy contrasts with multi-instance architectures, where separate software instances operate on behalf of different tenants” (Wikipedia)
Continue reading Multi-Tenancy
How to handle Events between Applications
The problem?
How can application A, handle events sent by an application B, and how to implements those events in B? Knowing that B has no idea of the existence of A.
Continue reading How to handle Events between Applications
Design Patterns
Sometimes, a solution is so beautiful, and you wish you had the right problem to apply it to. But unfortunately, issues come first. As impressive as your new screwdriver may be (imagine a handle made of gold, with your initials engraved, of course, if the problem at hand is to knock in a nail, it makes for only a less than perfect solution.
Now, after teaching you all I know about manual craft, let’s return to software development – and consider “design patterns” as your toolbox. Every design pattern you know (and understand) is an instrument in your toolbox. It’s certainly great to have many of them!
The problems start, however, as soon as you let the patterns dictate your coding. They should be there to support you, to propose a proven solution – for the right problem! Programming paradigms should be used where they fit and not be enforced. Your components should be designed with your application’s requirements in mind – not with a beautiful design pattern.
In cases where you’ve indeed found a helpful pattern for your current problem, there’s only one more thing: be sure to understand the pattern and its consequences on your coding.
Creating Good APIs
I’m sure you’ve used a third-party API at some point in your dev career – for example, to create new contacts in your CRM, to send emails through a newsletter service, or to do anything else with a third-party service virtually.
If you’ve interacted with a couple of such APIs, you will undoubtedly have noticed some differences between them: using one was probably more pleasant than the other. It’s easy to see which API was designed thoroughly, by an experienced developer, and perhaps with a lot of effort and thought. And it’s just as easy to be frustrated with an API that was designed poorly and sloppily. The former was probably a joy to use, while the latter was perhaps… not.
Since the effects are so visible, most developers tend to quickly agree that it’s almost a duty to design public APIs in a careful and thought-out way. Nobody wants to work with a crappy API – and nobody wants to burden other developers with using their API being crappy.
Modern software design puts great emphasis on the concept of “application programming interfaces”. However, as most developers already know, the idea goes a lot deeper and is not exclusive to a public interface. Instead, you should build APIs inside your application, for internal use, too.
Approaching these internal APIs in the same way you’d create a public one can make a huge difference: your colleagues (and you) will want to interact with this part of your application. Making the interaction as easy as possible for these people is one of the best goals you can have.
A secure, thoughtful API is probably the part of your software where quality matters the most. Your colleagues might forgive you a little sloppiness in the internals of this or that method. But they won’t (and shouldn’t) forgive you for creating a dangerous API.