Build an API with PowerShell & Azure Functions - Ben Reader - PSConfEU 2023

I, Ben Reader, discuss the necessary components for the Function App environment to run smoothly. These components include AZ accounts, AZ storage, and AZ resources. During a cold start, the Function App retrieves these components from the PowerShell gallery. I advise against uncommenting and grabbing the entire AZ PowerShell module, as it can significantly increase the cold start run time. It is suggested to identify the specific parts of the AG modules that are needed and specify only those. Inside the profile.ps1, there is a custom class called "ToDoTask" and a table entity to facilitate requests.

Listeners ask questions about module requirements and custom modules in the directory. I explain that modules specified in requirements will automatically pull down additional modules if needed. Adding custom modules to the directory is more complicated and requires using Kudu or similar tools. Alternatively, custom functions can be added to the profile.ps1 file for simpler inclusion. I provide a link to a resource that includes helpful functions for working with Azure Tables, and I explain that the author's code is used due to its compatibility with managed identities. However, the code is not published in the gallery, so it cannot be pulled down as a required module.

I discuss the contents of the profile.ps1 file, including various helper functions for storage table manipulation. Then, I move on to the run.ps1 file, explaining the presence of the auth context and the limitations of using managed identities locally. To enable local development, I share a link to a gist containing the necessary secret information, which can be copied into a local.settings.json file. This file is used for local development and contains custom fields such as table name, storage account name, and storage account key. The storage account is provided by default and can be leveraged by the Function App for its operations.

We are now ready to work with the storage account and verify its correctness. Next, we need to get an instance of the table context using our authentication. We will switch between the GET and POST actions. The GET action retrieves all tasks from the table, while the POST action adds new tasks to the table. We have a cheat sheet with the code for these actions, which we will copy and analyze. For the GET action, we search for table storage rows with a partition key of "to-do". If needed, we can optimize the search by using different partition keys based on the state of the tasks. Once we have the results, we create a list of to-do table entities and add each result to that list. We then store the list as a variable called "body". The status code is set to OK, but if any issues occur, we change it to bad request. For the POST action, we check if there is any data in the request body. If not, we immediately return a bad request status. If there is data, we create the necessary parameters and send the POST request. We return the content of the request so that we can see the payload we just created. Finally, we have an output binding for the function. We save everything, run the function, and check the ThunderClient to see if the GET request is working properly.

I update a task that was already in the system without a specific task assigned to it. I mention that I will tag tasks with the person who made the request in order to follow up on them. I note that we should implement error handling for empty tasks. Despite the tasks being empty, we proceed to create a task specifically for those who aren't trying to cheat. We run the code and verify that the task is added to the table. We highlight that the database is storing unstructured data and can be expanded as needed.