The Strangler Fig Pattern Explained With .NET 10

We all love working with legacy applications, right? Well, maybe not. So, in this video, I want to show you how we can use the Strangler Fig pattern to migrate our legacy APIs into modern. NET 10, and we can even use this to migrate from a different technology stack, like let's say a Node. js API into a. NET API. So, let me show you how. Let's say this is our starting point. We've got a Node API and a relational database, for example, Postgres, and we want to migrate this Node API into a. NET 10 API. Now, we can't do a complete rewrite as this would take a considerable amount of time and it would be error-prone. So, we want to do a step-by-step migration, and this is where the Strangler Fig pattern comes in. Now, everything I'm going to show you here also applies to something like a. NET Framework solution that you no longer want to maintain, and you want to migrate it into. NET 10. So, we're going to break this down into a couple of steps. Let me outline them here. First, we're going to add a reverse proxy in front of our APIs. For this, I'm going to be using YARP as it's native to. NET and it has all of the capabilities that we need to pull this off. Then, we want to migrate one endpoint from the Node API into a new. NET API that we're going to introduce, and then we effectively want to repeat this until the migration is complete. Let me just adjust this so that we can see everything nicely. So, these are the couple of steps that we're going to follow, but first, let me show you the Node API and how it works. As I wanted to keep this example simple, I've only got a simple Express API that connects to my Postgres database, and it exposes a couple of CRUD endpoints. So, we'll be working with some products database, and we've got endpoints for fetching the products, inserting new products, updating them, and deleting them. I've also got a simple Docker Compose file that's going to run my Postgres instance, and it's going to initialize it with a sequel script that will create the required table and insert some dummy products inside. So, to run this, we need to do a docker compose up from the root directory. So, inside of my terminal, I'm going to say docker compose up. Now, this is going to run my post dress database and also scaffold my initial table structure. If we open up docker desktop, we'll be able to see our database running inside of a container and then in our node app, we can open up the terminal and I can say npm start. If this is the first time running this, you're also going to say npm install and this is going to spin up our node API on localhost 3000. Then I can jump into something like postman and calling localhost 3000 and specifying the correct endpoint is going to give us the desired result. So, I can fetch all the products. I can get a single product by specifying the product ID. So, if I send this, we'll get back the details. If I send an ID that doesn't exist, we'll get not found. If I want to create a new product, I can send a post request and we'll get the product ID in the response. And now if I send this request, we'll get a response back. And we also got the put and delete endpoints. So now, we want to migrate this step-by-step using the strangler fig pattern. So, we first have to add a reverse proxy. This is going to slightly change our architecture from having just a node API and our database into this setup here where we've got a reverse proxy inside and our node API can now be hidden from the outside world. So, let's place a boundary here and any request coming into our system first lands on the reverse proxy and then it sends the respective request to our node API that actually serves the response. So, let me show you how we can implement this. I'll start from a blank Visual Studio solution and I'm going to add a new project here. I'm going to choose an ASP. NET Core Web API and I'm going to call this the reverse proxy. Let's click next. I won't be using HTTPS as we don't need it and I want to run this on. NET 10. Let me create this. This is going to scaffold my initial structure where we can basically get rid of everything except the basic setup needed to run this API. I'm also going to delete the scaffolded HTTP file and I want to update my launch settings to run this on port 8080 for example. Then we need to install our YARP proxy library. So let me look for the YARP NuGet package and I will install the latest version of YARP reverse proxy. So let's go ahead and add that. And how do we configure this? Well, we first need to configure some services. We'll say builder services add reverse proxy and we want to load this from a configuration section. We're going to define this in our app settings JSON and the config section name is going to be reverse proxy. Now I need to pass this in by saying builder configuration get section and pass in the respective section name. So that's part one. And then I just need to say map reverse proxy and we've turned our API into a reverse proxy using YARP. Of

course we're missing the actual reverse proxy configuration. So I'm going to add this in my app settings development JSON. Inside of this section we need two more configuration sections. Routes which is going to configure our proxying rules and clusters which configures our downstream servers. So for the first cluster going to define the node API and for this API I need to define the array of available destinations and then let's say this is destination one with the address being HTTP localhost and the port is 3000. So let's call this all node to represent that they should target all node endpoints and we first need to give it a cluster ID. So here we're going to use node API which is what we called our cluster in the below configuration section. Then, we need to configure how we want to match these routes. And I'm going to match them by the path, where I'm just going to define a wildcard called catch all, as this will match any incoming request. Also, to allow us to more easily figure out which API served the response, I'm going to add a request transformation, and I want this to apply to the response header. Let's call this served by, and we're going to set the value to the name of our cluster, which is going to be node API. So, this should be all the configuration I need to use YARP as a reverse proxy in front of my node API. Let me run this by saying control F5, and this should start my reverse proxy on localhost 8080. And now we can try to test this out. So, inside of Postman, I'm just going to replace the port and send the request, and you can see that we're getting back the same response as before, and we can also check if the response contains the served by header, and that is indeed the case, and you can see that the value is node API. So, now I'm going to just update all of these requests to use the 8080 port, which means they're going to be routed through our reverse proxy. And if we test out any of them, they should work just fine even when going through the proxy. If we take a look at the console, you can see that our requests are indeed being served through YARP. And this means that we can move into our next step, where we are going to introduce our. NET API. And what we do is we implement one endpoint from the node API inside of our. NET API, and then we configure YARP to route the request to the. NET API for this specific endpoint. And we effectively start implementing the strangler fig approach, where we move the functionality from our legacy system or a different technology into our new system, and we keep repeating this step by step. So, let's go ahead and add our. NET API. Inside of Visual Studio, I'll go ahead and add a new project. I'll pick asp. net core web API. Let's call this the products API. I'll click next. I don't want to use HTTPS and then let's scaffold this. And for now, I'm going to close everything else down and let's clean up the scaffolded setup to get rid of everything we don't need. And I'm going to configure our. net API to run on port 5000 for example. Now, all we need to do is to migrate the existing functionality into our. net code. And in order to save us some time, I'm going to go ahead and just install the required libraries, which are going to be NPGSQL because we're using Postgres as our database. And I'll install Dapper for just quickly executing our SQL queries. And then I'm going to drop in all of the code that's needed to make this work. And let me walk you through what's going on here. So, we're going to create an NPGSQL data source and basically re-implement the node functionality inside of our. net API. So, we've got minimal APIs for fetching the products, for fetching a single product, for creating a product, for updating the product, and deleting the product. Now, mind you that our API isn't publicly available until we expose it through our reverse proxy. So, let's see how we can do this inside of the YARP setup. The first thing we need to do is to define another cluster here. And I'm going to call this the. net API. And we're going to define the destinations. Let's say we've got a destination one just as in the previous example. And we're going to set the address to be HTTP localhost 5000. Now, how do we tell YARP or any other reverse proxy to route a specific request to our new API instance? Well, let's say I define a set of routes here that I'm going to call products read and I want them to use the cluster ID for the. NET API. And I also want them to take precedence over the matching node routes. So, with YARP, we can do this by defining an order on the individual route level. And a lower number indicates a higher priority. So, for the. NET API, I'm going to specify an order of zero. And for the node one. So, now I need to just match the respective

requests. So, let's add match here. We'll use path to make them match. So, to start, let's say I match just on the products route and nothing else. And let's also add our response transform by configuring the transforms array. And we're going to set the response header to be served by and we'll set the value as. NET API. Now, mind you that the whole time my YARP proxy was still running behind the scenes. And as I was making the updates into the configuration section, it was trying to load them into my running instance. As soon as I have a valid configuration, it's going to be able to load it. And I should be able to route my requests to my. NET API. So, let's set it as the startup project. I'm going to run it. And you can see it starts up on localhost 5000. And now if I try to send a request to fetch all of the products, we get a response back. But if you take a look at your response headers, you can see that this was served by our. NET API. However, if I try to fetch a single product, this is still served by our node API. So, if I update the transformation to make a match by using a specific HTTP method, let's say we're targeting get. And we want to expand this to also have a catch-all wildcard so that we match the routes with the product ID in them. We should successfully match both product routes for fetching the products. We can confirm this by sending a request to fetch all the products. You can see we get a response back and it's also served by the. NET API. And if we fetch a single product through the proxy, we get a response back and it's served by the. NET API. The create request is still being served by our Node API, so we can also migrate this. And I'm going to update the route to be products because it's not only for reading the products. And I'm just going to add the post HTTP method into my YARP configuration. And now I should be able to send this request again, and this time it's served. NET API. We get the same response. The product ID is now six. I can send a request for that here. That also returns 200 OK, and it's served by the. NET API. So, let's update this to also target the put and delete HTTP methods, and we're going to save this. And now I should be able to send an update request for a specific product, and you can see that this is also served by the. NET API. And let's try deleting a product with an ID of six, for example, and this is also served by the. NET API. At this point, we've completed our migration, and we can decide what we want to do with the legacy system. For example, I can just delete the routing code from my YARP configuration, and move everything into our new system, which is our. NET API. So, at this point, we've completed our third and final step. At this point, we can, for example, remove our Node API from the system and have everything flowing to our new API, which is running. NET. And hopefully, you now understand how you can apply the strangler effect pattern to a larger system. Obviously, a real-world migration is going to be more complicated. You will probably be using feature flags to manage which APIs are currently exposed, and I'm going to also leave some documentation for you in the description of this video if you want to learn more about the strangler effect pattern. And if you want to take this further and learn how you can use feature flags, I recommend taking a look at this video next, where I show you some interesting advanced usages for feature flags in. NET. If you like this video, consider gently tapping the like button. Thanks a lot for watching, and until next time, stay awesome.