If you don't know, Function Apps are one of Azure's Serverless offering. They are small pieces of code that you can write in C#, F#, Javascript and Java (with more languages coming). Being serverless doesn't mean that the code doesn't run on a server, it certainly does, it just means that you can think less about servers. Functions can be triggered by a number of events, the one we will focus on is a HTTP call. Each function that gets created has its own unique endpoint that can be called from anywhere. In this tutorial we are going to create a very simple API that responds to Gets and Posts calls, add a proxy in front of the functions and test everything in postman. Let's get started. To begin go to the Azure Portal, sign in and create a new Resource Group that will contain your functions. It is a recommended practice to house all the things needed for an application (like the functions, data store, message queues, etc) in a single resource group. We now have an empty resource group. Let's fix that and add a function app. On the resource blade click Create Resource. Next search for Function App and create one from the Web & Mobile category. This function app is a container for functions. We will be creating the individual functions later. Next we will name our function app, choose a subscription, hosting plan, OS, and storage plan. The app name must be unique within all of Azure, not just your subscription or resource group. I'm going to name my app and turn on Application Insights but other than that I'm going to keep the defaults. Now after we've created the function app let's go back to the resource group. At this point we should see 4 resources in the group; an App Service Plan, Storage Account, App Insights Account, and an App Service plan. The App Service plan is where we will be creating our individual functions so click on it. Let's create a new HTTP triggered function with F# and call it FSharpGet and change the Authorization level to Anonymous. Now we have created a basic function that will something like this. By default this function will respond to all HTTP verbs. If you click on the Get Function URL button you will get a popup with the URL you can copy to Postman and use to test out the function. Click on Integrate so that we can change the function to only listen on Get requests. Next let's remove all the code form the function that gets the name from the body (lines 26-31). Now if we omit the name query string parameter the function will return a 400 Bad Request. Next we need to create another function that will handle POST requests for us. Now that we have our functions created we will create the proxies for our functions. While your App Service is open, click on the Proxies group. Each proxy can only route to a single function so we will need to create one for each function. Creating ProxiesNote: As Anthony Chu pointed out on twitter, you do not need proxies for the first two use cases. Azure Functions support route templates and specific HTTP Verbs. Click on the plus sign next to the Proxies group. You will see the Create Proxy screen. Enter the name, Route Template, Backend URL and change the Allowed HTTP methods to Selected and then select Get only. Use the function URL that you copied from the function page as the Backend URL. Click Create and then repeat for the POST proxy, just make sure to use the same Route template as the Get proxy. We have now created 2 functions that each handle a specific HTTP Verb and 2 proxies so we can share a more user friendly URL with anybody calling our service. But what about the other verbs? If we try hit our proxy with any verb other than Get or Post we will get a 404 error. That may be enough for us, but proxies have the ability to override the request and response. What would happen if we created another proxy to handle the other verbs? Same as before we need to give this proxy a unique name, the same route template as the other proxies and select specific HTTP verbs. This time we are going to select all the verbs other than Get and Post. Backend URL is an optional field, since this proxy to handle errors we will leave it blank. To show the power of proxies, let's change the status code, message, headers, and body that gets returned to the caller whenever they try to get our proxy with something other than a Get or a Post. Finally click Create. Now that everything has been created it is time to open up Postman and test our end points. Using Postman we were able to verify that Get and Posts work as expected and that when we tried some other verb we got the status code, message, and response that we setup in the Error Proxy. The endpoint are very simple and don't connect to a data store, but I hope you can see the power of combining functions with proxies. Thanks for making it this far and Happy Coding.
Sean Wernimont The Blind Squirrel Copyright 2015-2020
|
AuthorWelcome to The Blind Squirrel (because even a blind squirrel occasionally finds a nut). I'm a full-stack web and mobile developer that writes about tips and tricks that I've learned in Swift, C#, Azure, F# and more. Archives
April 2018
Categories
All
|