API Framework, the moving parts

In my last post "Starting my API journey..." i wrote about my plans to create a framework that eases the development of web APIs.

In this post i'm going to outline my current ideas about the parts the framework should include and how they relate to each other.

So what parts should an API framework include? Of course, my ideas are very opinionated. But this are the parts that always made my life as a developer hard.

Gateway

The gateway acts as a reverse proxy that builds the boundary between the clients and our services. When a client calls an endpoint the gateway redirects the call to an internal service and returns the response. If desired it can provide additional features that so that we don't need to implement them in our services.

Possible additional features are:

• Throttling
• Authentication / Authorization (using an identity provider)
• SSL Termination
• Analytics (using a telemetry service)

In my framework i will use YARP. Yarp is an open source reverse proxy built by microsoft. You can read a short summary about YARP in the announcement post.

Logging / Telemetry

Logging, telemetry and analytics are an important part for every API. Identifying problems and bottlenecks early is important to keep our customers happy and the system healthy. The telemetry service should handle task like:

• Storing and analyzing logs / errors
• Provide usage statistics, execution times, etc.

For the logging part i will use serilog.

Identity Provider

The most APIs need some kind of authentication / authorization. Unfortunately this is one of the hardest parts. There are a lot of libraries / frameworks out there to do this. But either they are not able to handle multi tenancy or they are very complex. And mostly you need to have more security know how than you want. I want to provide a security solution that is easy to use and provides a lot of features. I think this will be the hardest part in my framework.

I want this part to provide the following features:

• OAuth2 / OpenID Connect workflows
• API Key Authentication
• Session based authentication (so that we can use it for simple websites)
• Multi tenancy support (one user can have different credentials for different APIs)

The biggest problem here is that there is no real open source solution that could provide this features. Microsoft does not provide something good. There is ASP.Net Identity with no support for OAuth and multi tenancy. So i guess i will go for Duende Identity Server. It's not really free, but open source projects und small companies will not have to pay for it. It is really sad that there is no really open source alternative in the .Net world like Keycloak in the java world. If you know an alternative just leave me a comment.

Task Scheduling

Task scheduling isn't really a crucial part of an API framework but it can make your life very convenient. Often you need to run tasks on a regular basis. Then you start creating shell scripts, batch files, etc. that you trigger by the windows task scheduler or linux cron jobs. It is far more convenient to trigger an API endpoint on a schedule.

For this part i will use hangfire.

Configuration

We have to deal with a lot of configuration settings in our projects. Usually we store stuff in the configuration files of our APIs (web.config, appsettings.json, etc.) or in some database tables. Using config files has the disadvantage of redeploying our services when settings change. Storing the stuff in the database of our services clutters everything. The goal is to provide a central configuration system that you can use. Currently i have no idea which library i can use. Maybe you have some ideas.

Common UI

All the features are very nice. But we want to view logs and telemetry data. We want to configure the gateway, identity provider and all the other parts. Of course we can do this by editing database tables or config files by hand. Ok, no! There should be a UI where we can do all this stuff. For this i want to create a Blazor SPA that provides a UI to do all this.

Next stop

So whats next? Until now i didn't talk about naming. One of the hardest parts in software development :). I will think about some name and then create an initial github or gitlab repo.

After that the first thing i will implement will be a simple gateway and telemetry (logging first) solution.

^{Photo by Thomas Hawk. License CC BY-NC 2.0}