Low-code / No-code API – Part 100 – Azure Function

Link to Part 11: https://programmium.wordpress.com/2020/11/23/low-code-no-code-api-part-11-azure-api-management/

Link to webinar: https://tiny.cc/nocode-azure

Ensuring Serverless in B2C API

So far in the previous 3 posts in the series, we’ve seen how to ensure the serverlessness in a low-code/no-code web api development. In this one we’re going to see how to ensure serverlessness when the API is about to be consumed by actual consumers – the last node in the chain.

Using Azure Functions, even though its not “no-code” but with less amount of code, without worrying about the ceremonial main functions, class declarations, interface abstractions etc, we can quickly let a small code block to execute in the cloud – “low-code”. Azure Functions has both consumptions plan and app service plan. App Service Plan is to ensure the piece of code is always hot – meaning it does not require any warm-up time to execute. On the other hand consumption plan is there to save the pennies. With consumption plan, you’re billed per function execution.

Authorization and Anomymous Access

Similar to Azure Logic apps, Azure Functions can be triggers via HTTP calls, Timers, Queue message arrivals, etc. But usually the HTTP trigger is the one thats being used most of the time to trigger a function – which is basically like a Web API implementation. Having said that, Azure Functions does support both anonymous access and authorized access.

Authentication / Authorization blade for a Function app

By default “anonymous access” is selected in the HTTP trigger, so whoever has access to the endpoint can just invoke it. But in the B2C scenario, to ensure the callers of the API are known people, and to restrict access we can use the App Service Authentication. Once this is configured, the HTTP call must be accompanied with an HTTP authorization header with a bearer token defined.

Usually the authorization is handled by the function app itself, we don’t need to write any specific code in the function to handle it, unless we need to do some custom validation or to make a customized execution. In that case, we can always use the HttpRequest object of the function invocation to access the HTTP header.

Accessing the Application Settings

We can use the Application Settings to store the values of the “Ocp-Apim-Subscription-Key” which should be provided in the HTTP header to invoke the Azure APIM gateway to access the B2B API.

Configuration blade of the Function app

To retrieve the values saved in the function, we can use Environment.GetEnvironmentVariable method in the function code.

You can have a look at this repository on how the portal function are implemented to make both GET and POST calls the Azure APIM of the B2B API.

And this completes the entire series.

Happy Coding!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s