Creating a Serverless RESTful API with Azure Functions Part 1 – Introduction

Azure latest (and in my opinion greatest) trend is Serverless, it’s cool, anything serverless can scale seamessly and if done right, be elastic and adapt to a dynamically changing load… which makes it ideal for implementing Microservices..

That said I am pretty new to Azure at the moment but nonstop learning, about in 1 or 2 weeks to face the AZ-203 exam as mentioned some weeks ago

But I like to play and this is the outcome of some trying and managing to get something close to a “proper” REST API endpoint in Azure, along with OpenAPI and some Azure provided goodies..

What and how?

So, what will we exacltly be doing and how will we do it?

I will be implementing a REST API endpoint using Azure Functions through a HTTP Trigger and C#, implementing it with Visual Studio 2019.

Then, I do plan to implement OpenAPI support with Azure API Management, which has several benefits as getting the documentation and test layer done almost automatically for us.

This said, I initially had thought of using an Azure Function Proxy (introduced by the end of 2017) as the front-end for the implemented API, which as well as some benefits like redirecting it to a Mock while the API is in development or being able to play between a Staging and an experimental new version of the API, etc.. But it seems that API Management does this and much more so I am unsure I will be using this feature… to understand it, this diagram might be of help:


So basically the Proxy acts as a facade between a user-consumer-publisher of our API and our API (Azure Function on the diagram). There we can do transformations of the request, response, redirect it to another Azure Function or service, etc..

As said, I’ll use API Management and not dig into Azure Functions Proxies.

Also, I do not plan into digging into authentication-authorization but that might change as we progress into it.


Azure Functions 101

Azure Functions are a great solution for running quick functions, this meaning 2,5 minutes for a HTTP based response (usually 5 minutes, modifiable up to 10 minutes).

They can be implemented with several languages, including C#, and supports dependencies as NuGet.

They Support integrated security with OAuth as Azure Active Directorz, Facebook, Google, Twitter, etc..

Integrates perfectly with various Azure and 3rd party services.

FaaS/LaaS or PaaS – mainly they are Serverless so that means “Function as a Service” or also named “Logic as a Service” but we can change the pricing plan from the default “Consupmtion” to “App Service”. So, basically a “Web API”. That said, the Consumption plan right now comes with 1 million executions for free a month, which is not bad, right?


Azure Functions Proxies

The Azure Function Proxies act as a single URI, a unified facade which we can use some redirections and transforms to our convenience, like:

  • Request and Response overrides.
  • Modify input request to send different HTTP verbs, headers or query parameters to a hidden backend service.
  • Replace Backend response status code, headers and body.

This said, API Management supersedes Azure Function by large. That said, they have their role, if we only want to unify separate functions or API services into a single API, we should use Azure Functions Proxies.

If we want a API Management, then we know what to use.

That said, it might be interesting if we have a somehow complex environment. As said, an image is worth 1000 words:


So it could be used to unify several related API micro-services, whilst having a greater API facade which Manages them all.

Or to mock an Azure Function..

As we will implement something way simpler, I’d go for the API Management. Also, it seems more fun.


API Management

API Management enables a full fledged professional facade/gateway for our API, providing in-built services which support all that the Azure Functions Proxies can do plus:

  • Load Balancing
  • Hot Swapping
  • Rate limiting
  • Authentication and Authorization
  • IP Whitelisting
  • Access Policies
  • Caching
  • Subcriptions, including User and RBAC management
  • Licensing
  • Business Insights & Analytics
  • Developer Portal (for ISV partners and-or internal use, including API documentation, interactive console, account creation and analytics on own usage..

API Management was launched on December 2018 and the consumption plan (which I plan to use) has been recently released (it was in preview) by the end of May 2019. the announcement clearly says that it is specifically meant for microservices.

Read more on the official Microsoft documentation on API Management or just get the whitepaper.



And that’s it for today, on our next entry we will create and verify our first REST api in C# with Azure Functions.

Happy coding!

Implementing a Strategy to “rule them all…”

The Strategy pattern

The Strategy pattern is one of the OOP design patterns which I like the most..

According to wikipedia, “the strategy pattern (also known as the policy pattern) is a behavioral software design pattern that enables selecting an algorithm at runtime.” – source

This UML diagram showcases it Pretty well:

Why I like it?

I believe there are several reasons that make this design pattern one of the most useful ones around..

  • Improves the KISS (Keep It Simple and Standard) principle on the code.
  • LSP – The “Strategies” are interchangeable, can be substituted by each others. This is a clear aplication of the L in SOLID, the Liskov Substitution Principle or LSP: “Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.” – Source
  • Open-Closed – The Strategy implementation through an interface is a clear application of the “Open-Closed Principle: “software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification”. In this case we can extend it by writing a class that extends the behavior but we cannot modify the interface. Even more, if we implement the Strategy using a Plugin implementation we do not even need to modify its source code. It’s a very clean implementation. It also helps into Decoupling the code and responsibilities. – Source
  • SRP : We can strongly affirm also say that the Strategy promotes the Single Responsibility Principle as each Strategy implementation should be implemented in a single class.
  • DI: And also, the Dependency Inversion Principle: “One should “depend upon abstractions, [not] concretions.”  – Source. This is so as the Strategies depend on abstractions, an interface which defines the strategy.


We can easily implement the Strategy pattern with Dependency Injection but this makes that the code of the Strategy to be on the same assembly or executable and thus, coupled. Due to this, I consider this as a sub-optimal implementation which does not fulfill the Open-Closed principle at 100% if we consider the main Executable as a “Software Entity”.

Even more, if we are in a highly regulated Environment, this means that we can add functionality without altering “the main software” which might be subject to a regulated process like FDA-approval, in case of a medical system… that means several months of documentation, testing and waiting for FDA to sign everyhting. 

Do you like it already? Wait – there are more Benefits!

In my previous work, at RUF Telematik, I proposed the application of this pattern with a plugin system as part of the Technical Product Roadmap. Basically to decouple the code which interfaces a concrete hardware (type of HW, manufacturer, version…) So the main software would not need to know how to talk with a camera, monitor or communication device in the train System. The responsibility is delegated to a .dll plugin that knows how to do that work and we can dynamically add These Features without altering the main software.

In addition to the software architecture benefits and the code quality, we have some more benefits:

  • We can parallelize the development of the Hardware Manager dlls to different developers who can test them separately.
  • We can separate the release and test workflows and accelerate the development time.
  • We do not need to test the main software every time we add support for a new device or version of a device firmware..
  • We do not need to revalidate through industry standards the full software over and over again (usually with an substantial cost of time and money)

In a train we could categorize the different hardware on it on hte following four categories:

  • TFT screens
  • LCD Screens
  • RCOM Communication devices
  • Camera devices

Each one has different Vendors, models and version numbers so a bit more complex implementation should be needed but this is an example so we do not Need to build “the real Thing”.

So we could implement an interface like ITrainInstrumentManager that supported methods like:

  • Connect
  • Getversion
  • Update
  • Check
  • ExecuteTests
  • UpdateCredentials
  • and so on…


And then implement a Strategy that fulfills this interface for every Type of Equipment, for every brand/vendor and for every model and version…

With the added Benefit that I can parallelize this work and get several persons to work in different Strategies, one for each new device. This would enable to add support for new hardware devices in no time at all.

And they could be tested separately, with the warranty that if the tests do work, the main tool would work as well.

Without altering or releasing the tool, just adding the plugins in the corresponding folder or loading them dynamically from an online service or location. (if we implement the strategy using the plugin technique, of course)

This presentation showcases some of the points mentioned above, if you are still curious.


Implementation of the Strategy Pattern

One of the best implementations I have ever been part of is when I worked along 2011 and 2012 at Parlam Software where a plug-in architecture was designed and implemented by my now friend Xavier Casals. Then he was my customer and CTO of Parlam (and still is).

<Commercial mode>

If you are in Need of translations, do check their solution. Basically it is a full fledged TMS (Translation Management System) which automates your language translation process. More on this here and here.

</Commercial mode>

This Plugin system enabled adding dynamically Data convertors to third party systems, like different CMS systems as “SDL Tridion”, to where his service connects and works with, so basically he can deliver an interface to anybody that wants to interface with its system and enables an easy implementation as well as testing and deployment. Once the DLL is tested and verified, can be signed for security reasons and added to a folder where it is magically loaded and we get the perfect implementation of Open Closed Principle…

“software entities… should be open for extension, but closed for modification”

I know it is a lot to say but let’s get it done and you tell me after 😉



We will create a .NET standard solution which will have implement 3 Projects:

  • StrategyInterface –> A .NET Core Class Library that will hold the Strategy interface, two custom attributes and a custom exception for managing the plugin. This is the basic contract that we will share between the main application that will use the plugin(s) and the plugins themselves.
  • Plugins –> This is a project with a simple class that implements the Interface on the StrategyInterface Project/Assembly. I will use the two custom Attributes to add a name and a description so I can programatically go through them with Reflection before creating an instance, which is convenient if I want to avoid creating excessive objects. Note that this Project will have different implementations, in our case I created 4: CAM, LED, RCOM and TFT. Each one will create a DLL in a concrete directory, “D:\Jola\Plugins”.
  • StrategyPatternDoneRight –> feel free to discuss with me on the name, comments are open to all ;). This is the main customer/user of the Plugins that implement the Strategy and will load the plugins that match the interface from a concrete location of the filesystem. At the moment I did not put too much logic but just to load all the matching assemblies and execute a simple method which all the plugins provide.

The solution looks like:

Strategy01 structure

StrategyInterface project

The most important here is the interface that defines the Strategy:

Strategy02 interface

There we will create the custom Attributes, one for Name and another for Description:

Strategy03 cust attrib name

Plugin project(s)

I created a Plugins Folder to contain them all, then created .NET Standard assemblies and added a reference to the StrategyInterface Project.

Lets say that we create the CAM.Generic Project to implement support for the Train Network Cameras… there we add a class which implements the Strategy Interface and we add the two custom Attributes to it:

Strategy04 Plugin Strategy Implementation

Obviously this is a simplification but here we would put all the hardware dependant code for handling complex network operations with the camera…

All the Plugin Projects are customized to have the same Build Output Path, to avoid doing Manual work:

Strategy05 Plugin Build properties

Just be Aware that the output path that you use must exist and be the same for all Plugins.

Main Application

So, all we have left is to implement the mechanism to recover the assemblies at a concrete filesystem path and load them dynamically into our current execution process. We will do this using Reflection.

I am creating a wrapper class for exposing the strategies implemented by our plugin assemblies.

This class is named StrategyPluginContainer and will expose the two custom Attributes and an instance of the Plugin (really it is an instance of the class that implements the Strategy Interface).

The two key reflection techniques used here are:

  1. Activator.CreateInstance(Type) – This creates an instance of the specified Type using the default constructor. Note this is not reflection but comes directly from System Namespace.
  2. Type.GetCustomAttributes(Attribute type, inherit) – this obtains from a type the value of a custom attribute.

Note: green is due to style suggestions from my VS installation to what I do not agree if I want clarity. Expression bodied properties or using ?? are good, reduce space but if somebody is not used to this Syntax readability and understandability are reduced..

Strategy06 Plugin Wrapper

Now we can implement the StrategyPluginLoader. This class responsability is to Keep a list of the Plugins that implement the Strategy and it does so by loading them from the Filesystem (could get them from a web service or other mean).

Basically it has a List of StrategyPluginContainer which we just created, exposed through a property.

And populates it by getting all the DLLs from a specific hard disk Folder and loading them with Reflection’s Assembly.LoadFrom(filename).

then we get the types contained on this Assembly and iterate through them to match them against the Strategy Interface. I also check that the two custom Attributes are supported and if everything matches, I create a StrategyPluginContainer instance of this concrete type.

As a final check, I verify if the Plugin is already on the plugin list for not repeating and if is existing I update it in a proper way.

Strategy07 Plugin loader

Last but not least, I use all this through a nice console application, I create the StrategyPluginLoader, I execute the command to load all the plugins and iterate through them invoking the only command in the interface which is implemented in separate, decupled assemblies and loaded dynamically at runtime, without no Knowledge or coupling of any Kind in the main application.

Strategy08 bringing it together

The full code can be found in GitHub here.


Happy coding!



Win A Free Copy of Packt’s Microsoft .NET Framework 4.5 Quickstart Cookbook

Win A Free Copy of Packt’s Microsoft .NET Framework 4.5 Quickstart Cookbook

[UPDATE: The contest will finish at the end of August]

I am pleased to announce that, with support from Packt Publishing, we are organizing a giveaway especially for you. All you need to do is just comment below the post and win a free e-copy of Microsoft .NET Framework 4.5 Quickstart Cookbook. Two lucky winners stand a chance to win an e-copy of the book. Keep reading to find out how you can be one of the Lucky One.


Overview of Microsoft .NET Framework 4.5 Quickstart Cookbook

  • Designed for the fastest jump into .NET 4.5, with a clearly designed roadmap of progressive chapters and detailed examples.
  • A great and efficient way to get into .NET 4.5 and not only understand its features but clearly know how to use them, when, how and why.
  • Covers Windows 8 XAML development, .NET Core (with Async/Await & reflection improvements), EF Code First & Migrations, ASP.NET, WF, and WPF

Note: I am posting this also on my new blog, http:\\, feel free to post it there (preferably) or here as I will watch out both sites.

Shape – the App conference

On the 9th of April, yesterday, I attended Shape, the app conference, in Baden, Switzerland.

There, I presented a session regarding Multi Targeting development for Windows Store and Windows Phone apps.

I had a lot of fun while writing the demo App with the surprise that on the night of the previous day, 8th of April, I tested around 23:00 pm my demo and it stopped working. After a while, saw that my demo’s OData provider was off… definitely!

You can read about it here:, but to keep it short “as of April 8th, 2013, this service is no longer available.” resumes it pretty well.

Anyway this was good because It took 5 to 10 minutes to plug-in another OData service, even it was never as cool as seeing the latest movies…

My slides and demo are on SkyDrive, available <<here>>

Thanks to Microsoft for the organization and the attendees for their interest!!

Fighting with VS 2008 SP1 Beta…

Two days ago, for writting an article about Silverlight integration with ADO.Net Data Services I decided to install Visual Studio 2008 Service Pack 1 (Beta!), just to find that after the install, that went wrong and with problems it got dll problems with Silverlight 2 beta 2…

I’m still at it as I did it at once in my two computers, Desktop (Vista ultimate sp1 (x64) and Laptop (XP SP2) and all are being “in processs” right now…

There are loads of information about this issue, being the main one and recommended at the Silverlight official website, there is some very interesting information at the Scott Gutrie’s blog, and others like the Web developers blog, And also there is an interesting article on  how to download all the SP1 (also mentioned on the sp1 documentation)..

Also, be sure to read the Visual Studio Service Pack 1 Beta documentation, it is worth it. As Agent 86 said, did you read the 467th page? 😉 Just joking but would be great if things weren’t sometimes so complicated..

As on where am I now, I did all the repairs and followed procedures on my laptop but somthings not working so I am uninstalling all and will install the sp1 again.. if that doesn’t work, will do this from a clean (again) Visual Studio 2008 Professional install..

As on the Desktop, I already did this (quad core & 8 Gig ram helps on this matters) and had issues installing the sp1 as it didn’t recogniced there was a Visual Studio installed… to say I had VS Team System 2008 and thinking this was for this, I unistalled and installed the professional version.. but still doesn’t find it! and it is installed!! so I am downloading the vs 2008 sp1 manually to try installing it piece a piece… let’s see..

If anybody wants to suggest other way of actions, I’m fully open..

For now, these are my 5 cents..