Dynamic API Extension in ASP.Net Core

 Introduction

This article describes about extending API in asp.net core dynamically at runtime. This means we do not have to recompile the code again if there are any new API is introduced. We can develop the extension project in a separate solution and deploy only the dll file to the server.

Some use cases of this project are,

1.       Create a dynamic API at runtime and add the API to existing server.

2.       When a third-party team want to extend the API for their own use.

3.        A scenario in where we do not have to deploy the extended services as a separate microservices.

Some advantages of using this architecture,

1.       Modularize the project, so that it is easy to maintain different parts of the project.

2.       No need to restart the server for deployment.

3.       Restrict the extension API instead of giving full control to the third-party team.

Architecture

This architecture uses the application part and assembly part from the asp.net core to extend the controllers. An application part is an abstraction over the resources of an app. Application Parts allow ASP.NET Core to discover controllers, view components, tag helpers, Razor Pages, razor compilation sources, and more. Assembly part is an application part. AssemblyPart encapsulates an assembly reference and exposes types and compilation references.

Image 1 Plugin architecture diagram

From the above architecture diagram the Plugin Framework in the interface between Base API and PluginOne project. This way the Base API identifies the plugin and registers within. The Plugin are developed and deployed independently regardless of the Base API. It then deployed to the Base API root folder. The Base API now discovers all the APIs that is within the added plugin and publish those API along with the Base API. Users and clients now can invoke the API from PluginOne

Plugin interface

The IRegisterService interface is the base framework where all the extended library should be implanted. The IRegisterService acts as a plugin interface and bridges between our main application and plugin.

namespace PluginFramework

{

    public interface IRegisterService

    {

        string ServiceName { get; set; }

    }

}

Listing 1 IRegisterService interface

The IRegisterService interface is used as type to search for plugin by main application. Listing 1 shows the interface where it has only ServiceName as member variable. The service name is the name of the plugin and used the main application to identify the plugin.

The below Listing 2 shows how the plugin got registered itself by using the IRegisterService interface. The “PluginOne” name is used by our main application to identify the plugin.

namespace PluginOne

{

    public class RegisterService : IRegisterService

    {

        public string ServiceName 

        { 

            get => "PluginOne"; 

        }

    }

}

Listing 2 Concrete implementation of IRegisterService interface by PluginOne

Registering plugin

The below piece of code extracted from ‘PluginStatusController.cs’ where we post the REST api to register the plugin with main API project. The API takes the PluginStatus and the model contains the plugin name. By default the plugin dll copied to the ‘Plugin’ folder within the root directory. The LoadFromAssemblyPath load the dll module and attach to the running process. Then the file is added to the application part which enables the process to identify the controller built within the plugin.

 [HttpPost]

 [SwaggerOperation(Summary = "Upload a plugin to activate", Description = "Upload a plugin to activate")]

 [SwaggerResponse(200, "All is OK")]

 public PluginStatus Post([FromBody] PluginStatus plugin)

 {

    string path = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "Plugin");

    if (Directory.Exists(path))

    {

        string assemblyPath = Path.Combine(path, plugin.Name + ".dll");

        var assembly = AssemblyLoadContext.Default.LoadFromAssemblyPath(assemblyPath);

        if (assembly != null)

        {

            _partManager.ApplicationParts.Add(new AssemblyPart(assembly));

            // Notify change

            ActionDescriptorChangeProvider.Instance.HasChanged = true;

            ActionDescriptorChangeProvider.Instance.TokenSource.Cancel();

        }

    }

    

    return new PluginStatus

    {

        Name = "Plugin1",

        Version = "1"

    };

}

Listing 3 Registering the PluginOne with BaseAPI

Extension controller

The extension controller implements the simple API controller with the operations defined. In our example we had implemented OperationOne API. The sample code is shown below,

namespace PluginOne.Controller

{

    [ApiController]

    [Route("[controller]")]

    public class OperationOne : ControllerBase

    {

        private static readonly string[] Summaries = new[]

        {

            "Freezing", "Bracing", "Chilly", "Cool", "Mild", "Warm", "Balmy", "Hot", "Sweltering", "Scorching"

        };

 

        [HttpGet]

        [SwaggerOperation(Summary = "OperationOne Get API", Description = "This method is from CustomerOne module")]

        [SwaggerResponse(200, "All is OK")]

        public IEnumerable<ModelOne> Get()

        {

            var rng = new Random();

            return Enumerable.Range(1, 5).Select(index => new ModelOne

            {

                Date = DateTime.Now.AddDays(index),

                TemperatureC = rng.Next(-20, 55),

                Summary = Summaries[rng.Next(Summaries.Length)]

            })

            .ToArray();

        }

 

        [SwaggerOperation(Summary = "OperationOne Post API", Description = "This method is from CustomerOne module")]

        [SwaggerResponse(200, "All is OK")]

        [HttpPost]

        public ModelOne Post(ModelOne modelOne)

        {

            return new ModelOne { };

        }

    }

}

Listing 4: Sample PluginOne extension controller

Running the extension service

To test the extension plugin, run the Base API service. The below screen shot shows the swagger documentation for Base API before the PluginOne integrated. As you can see the swagger doc contains only the API we defined in Base API.

 

Image 2: Swagger doc after PluginOne integrated

To see the extension API, copy the PluginOne.dll file from the PluginOne project to BaseAPI root folder\Plugin folder. The call the POST method of api/PluginStatus and pass the following json object in the body,

 {

    "name": "PluginOne.dll",

    "version": "v1",

    "activate": true

}

Listing 5 Json body object to be passed in api/pluginstagus

 

This call enable the PluginOne attached to the BaseAPI process. Refresh your page again and you will now see the OperationOne APi listed in the swagger doc. The below after registration screen shot shows the same.

Image 2: Swagger doc after PluginOne integrated

Sample Code

The sample code for the above discussed project can be downloaded from this github repository.

Conclusion

Although in microservices architecture, an extension API can be installed in separate micro service. The above article is used in a particular case where API need an extension but still need to continue to be deployed as single monolithic application. This architecture is also helpful when security is considered where request and response is controlled.





Comments

Post a Comment

Popular posts from this blog

Debugging and Testing Helm Charts Using VS Code

Image
Introduction Helm charts are useful to manage, install and upgrade Kubernetes applications. Helm is a developer friendly templating Kubernetes resource files based on GO templates and YAML. The templates are written using any notepads and deployed using Helm. Writing helm commands on notepad is not user friendly. Using Visual studio code we can setup a workaround that will enable to code faster and see the generated Kubernetes YAML files.  The following document has the details of necessary steps and guide that will help you to debug and test your helm charts before directly installing in the Kubernetes cluster using Visual Studio Code. Download and configure Helm in windows Download the Helm.exe for windows from the link  https://github.com/helm/helm/releases  or  https://get.helm.sh/helm-v3.5.0-windows-amd64.zip . Unzip and copy the contents to some directory like 'C:\Users\<username>\Tools\Helm'. Configure the above directory URL to environment var...
Read more

Handle Multipart Contents in Asp.Net Core

Handle Multipart Contents in Asp.Net Core Introduction When we program a web API in ASP.Net core we usually we have the Content-Type header as ‘application/json’ if it is a REST API. Assume a scenario where we need to pass an image along with description about the image or metadata. We can either pass that information in query parameters or in headers, but query parameters or header has limited in size. If the metadata is a json object, then query parameters or header is not a best place to pass. How about sending both the json and binary image within the body itself. There is a Content-Type ‘multipart/mixed’ in HTTP protocol is where we can achieve this. This article shows you how to pass both the json data and the binary in the same http request. Content-Type=multipart/mixed Header In the below example I will show how to use http header content-type as ‘multipart/mixed.’ The purpose of the Content-Type field is to describe the data contained in the body fully enough that the ...
Read more

Validate appsettings in ASP.net Core using FluentValidation

Image
Introduction In the ASP.net core all the application configurations are maintained in appsettings.json. The appsettings.json contains many settings like database connections strings, logging settings, and authentication settings etc. Applications settings are injected into the application as IConfiguration. Application uses these settings to perform certain tasks. For example establishing a connection to database. What happens when you update a wrong database connection string settings in your appsettings.json file? Shouldn’t we validate the settings before establishing a connection to database? This article shows you how to validate the appsettings.json while application starts. Why should we validate appsettings.json? There are some benefits validating appsettings.json, ·        Centrally manage the validations Applications settings are consumed in many parts  of the application. The validations of these settings are scattered across the code. Instea...
Read more