Toggling Code With IoC

In our development process we believe in microservices and the CICD philosophy. To achieve that we introduced feature toggles to control the features that were already delivered to the customers. So when the feature is stable enough we enable the feature on the next update and the new features are usable in the product.

 

With the passage of time and maturity in the product, we moved to tenant-based solutions. The biggest challenge that we faced in that was toggle functionality based on the customer. We had our toggles loaded in the start-up of the application. After the start-up, the objects were registered based on the toggle and the application was started. Now in case of single Tenant installation was not a problem as we could easily restart the customer to load the latest token. With a multi-tenant installation, it’s a bit hard to do, as we have to restart all the tenants in order to load the tenants.

 

So in this post, I am going to address this problem and also discuss the solution that we implement. So our old system had the following architecture.

 

There are my reference classes,

 

So I have  two services, service class On and service class Off. The service class On will be called if the toggle is set to ON; the service class Off should be called if the toggle is set to OFF.

 

Here is where I am using the toggle and the service so the following steps are performed in this class

1. Load the toggle
2. Initialize the service collection
3. Register, based on toggle
4. Initialize the service
5. Access the Serve method
6. Ask user if he wants to continue and if yes continue to step 5

Now when I run this code I will see the following output,

 

 

Now in this output even if I change the content of the toggles.txt the new toggles will not be affected until I restart the application.

 

So our solution was to handle it with some changes in the way we load and register the application. So instead of loading the toggle, in the beginning, we added that part in our interceptor. Before I got into details let me talk a bit about the interceptor.

 

In the old solution, we had toggle information loaded before we accessed the object. So we already know what type of object it was. In the new solution, we will write an interceptor that will be called every time we initialize that service object. Which will give us the opportunity to figure out the toggle before assigning the type of the object. Let's see the code for better understanding.

 

 

So the most important thing to note here is on lines 17,18 and 19. We register both the On and Off service and then we register the service interface using the Register Capability Components. The register combability is added via the extension method to the service collection.

 

 

Every time we access the “Serve” method this capability interceptor is called and the toggle is loaded to see the type of the object. This type is based on the provided toggles. So the toggles are accessed and the type is determined before the method invocation. Let's run the program again to see the output.

 

 

As mentioned above the toggles are updated by stopping the application and the latest change was impacted. This is how we solved the multi-feature multi-tenant dynamic invocation problem. I know that this could be done in a million ways and we could also optimize the code to be more efficient. This code example is just to highlight the problem and a potential solution.

 

The code is available here.