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.
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.
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.