Wading into the kiddy pool of Azure Web API
Microsoft’s Azure service has been around for quite a while now, but I’ve never had a reason to do much with it since many of my clients are not “in the cloud”. Until now, that is. One of my SharePoint Clients is undertaking an initiative to move from their on-premise server to SharePoint Online, which presents some unique challenges for the custom solutions I had developed for them over the years.
One of these custom solutions takes user data saved in a SharePoint list and generates a PDF document, then saves that document back to a SharePoint Document Library. My solution utilized PDFSharp / MigraDoc to create the PDF document from scratch, but it can not be directly ported over to SharePoint Online since you can’t install 3rd party DLLs for use on SharePoint Online.
After brainstorming multiple solutions to this mission-critical requirement for my client, one of the options we wanted to explore was utilizing Microsoft Azure Web APIs to generate the PDF. The requirements were 3-fold:
- Securely POST JSON data to an API endpoint
- Generate the PDF document in-memory
- Return the PDF document to the client in the response
I had never worked with Azure before, but it was my job to develop a proof-of-concept to see if this would be a viable solution to suggest to the client.
My first exposure to Azure can be summed in one word: Daunting. I created a free trial account, and as soon as I landed on the Azure Portal I was pretty overwhelmed. There were so many options and configurations to wade through on the portal itself, mentioning nothing about the various service plans or how usage affects your cost (something as consultants we need to be aware of when recommending options to clients). Very quickly I decided to fall back to the tried-and-true method whenever engaging in something brand new to me: find a tutorial.
I found a tutorial from Microsoft to set up a Web API project in Azure, and it was extremely helpful. Very quickly I was setup and developing a Web API project in my more comfortable Visual Studio / Localhost environment, and deploying my API to my Azure portal with one click. I really give props to Microsoft for this setup – it just works. One of the things I really enjoyed that the tutorial introduced me to is Swagger. At a high level Swagger provides metadata about your API, but one of the really useful features was the UI provided by Swagger which allowed me to easily test my API endpoints. When deployed into the cloud this was invaluable for quick tests of my API.
At this point I had a functioning Web API in Azure that I could easily access and test. Completing my proof-of-concept was easy enough and I was able to get a PDF generating from an API hosted in Azure and returned to the caller. The one thing I found myself frequently wishing I could do was remote debugging of my API once it was in Azure. I ran into one situation where my API functioned when run locally but would crash in Azure. I can’t imagine there’s no way to do this, or at least check your error logs, but I didn’t find an easy way to do this.
This roughly day-long exercised left me pretty impressed with Azure. I know that I barely scratched the surface of what Azure can do, but at least it no longer seemed as scary to dive into. To anyone debating trying out Azure, I say: take the plunge.