Fault Tolerant Web Service Requests with Polly

Course Overview
Hello everyone. My Name is Bryan Hogan. Welcome to my course, Fault Tolerant Web Service Requests with Polly. I'm a software architect, podcaster, and blogger. I love learning new things, and I love talking about and writing about them. Polly is a resilience framework for. NET. When I started using Polly, I was blown away by what it could do and how easy it was to use. The Polly library has been downloaded over 2 million times and has an active developer community. Using Polly will make your web requests far more reliable and your applications much more stable. It does all this with a minimum amount of code and is thread safe. You can use it with your. NET Core and Framework applications. In this course, I'm focusing on Polly in. NET Core 2 Web API applications, but almost everything I cover is applicable in Core 1 and the framework. I'm going to show you why web requests fail and why you need Polly. Then I'll get you coding with a simple, but super powerful retry policy. I'll show you how to reuse your policies across multiple projects and applications, and how to unit test your code before moving onto complex topics like caching, circuit breakers, and bulkhead isolation. By the end of this course, you will be able to use all the features of Polly to write rock-solid code, which not only keeps your application up, but also improves the performance and reliability of the services you call. Before beginning, you should be familiar with Web API and Web services in general. I'll go through everything else you need to know. I hope you'll join me on this journey to learn Polly with the course Fault Tolerant Web Service Requests with Polly at Pluralsight.

Learning the Basics of the Polly Framework
I'm Bryan Hogan. Welcome to my Fault Tolerant Web Service Requests with Polly course for Pluralsight. In this course, I'm going to show you how to use a Polly resilience framework to make your applications more resilient to transient faults and longer outages in remote services. Polly is a mature framework under active development, has an engaged community, and downloads in the millions. When I first started using Polly, I was blown away by how easy it was to use, how well it performed, and how much complicated work it encapsulated in a few lines of code.

Reusing Policies for Faster Development and More Robust Applications
Welcome to the next module. You now know how to make resilient web requests in a single controller. As you have seen from the examples, this was easy to implement and improved the reliability of your code enormously, but you also saw how the policy is located within the controller and could not really be reused in another controller. We're going to tackle that exact problem in this module, reusing policies across controllers, projects, and even solutions. As your application grows, you will have more opportunities to use and reuse policies. Imagine a scenario where you have 20 controllers, each with 5 action methods. If even a quarter of these are calling external services, you're going to need a way of sharing policies within your project. There's no reason why sharing should be limited to the project level. You could have a shared library of policies that handle common problems like internal server errors, timeouts, backoffs, etc. across a whole solution. This library could easily be turned into a NuGet package and distributed more widely. With a large array of policies to choose from, wrapping and chaining policies also becomes much easier. Consider the wider benefits to you and your colleagues when you have a shared set of policies that handle common failures. The amount of time you have to worry about fail requests will fall to almost 0. Over a period of time, you and your colleagues can tweak the policies to suit your environment.

Unit Testing Policies
Welcome to the module on Unit Testing Policies. Up to now, I've shown you how to use Polly's concrete policies on their own or as part of the registry or dependency injection containers. But because I was working with concrete types, it would not be possible to perform unit testing on a method where the policies were used. I'm sure that for many people the use of unit tests is not optional. But don't worry, Polly has you covered. Everywhere I executed a concrete policy, I can swap in an interface. The most important interfaces for us are the execution interfaces, IAsyncPolicy and IAsyncPolicy that takes a TResult as a generic result. These are very important because they provide the interface to the executeAsync method for retry, timeout, fallback, circuit breaker, and the cache policies. There are also interfaces specific to each policy, IBulkheadPolicy, ICircuitBreakerPolicy, IFallbackPolicy, INoOpPolicy, IRetryPolicy, ITimeoutPolicy, and IPolicyWrap. I'm not going to worry about them here, but you would use them if you wanted to test some of the other features than non-execute methods of policies, for example, the circuit state, or last exception, of the ICircuitBreakerPolicy. I'm going to backtrack a little from the reuse of policies I showed you in the previous module so that I can demonstrate testing a single policy passed into a controller with dependency injection. Then I'll show you how to test a registry and the other DI approach.

Combining Policies to Protect Against Many Types of Failure
I've shown you how to use individual policies to make web requests resilient, and I've also shown you how to combine these policies at the time of execution to make these web requests even more resilient. In this module, I'm going to show you how to wrap policies together before using them and then use the wrap to make the web requests. This makes it easy to combine policies that are commonly used together and then reuse these combinations. It also makes your code at the point of the web request execution a lot easier to read.

Improving Policy Execution with Information from the Caller
Up to now, the policies we've looked execute knowing only about the request that was made and the response that was received. The policies don't know anything about what is happening in the method where they're called from. In this module, I'm going to show you how to pass information from the method where the policy is executing to the policy as it executes. You might want to do this to write more detailed logging messages or to control the execution of a delegate.