Creating a node api app service in Azure

Posted by Alan Barr on Tue 08 November 2016

Thanks to my employment I have a Visual Studio Enterprise Subscription. One of the benefits of this subscription is a monthly allowance of $150 dolllars to spend on Azure services. I have experimented with many of the cloud providers offerings and these days they all offer similar services. Generally each will have some version of the same thing. I have wanted to experiment with building an app service on Azure.

As part of my experiments in load testing I learned how to setup Azure Functions to write logs to a storage table. I had a new use case for an application I wanted to build and with Azure there is definitely more than one way to develop an application. Since I knew Azure Functions so well I figured I might start there until I had refined my prototype. One challenge I have had in the process of developing on Azure is I do not quite understand how to control and monitor my costs. I experimented with using the machine learning platform with a beefy machine and found I started to burn through my credits quickly exhausting the account. Once I had exhausted the credits I had to wait the next month and then I had still forgotten to stop and delete the virtual machine.

In an attempt to manage costs I figured I would keep trying the Azure Functions and see how that goes then see if an App Service might be cheaper. As part of my app I know that I need to communicate with the pivotal tracker api to get data about my team's current iteration to craft a burndown chart. This first began with using Microsoft's Kudu system to login to the function service and install the dependency I needed for initiating API requests the request module/library. Once I had that installed I could craft my API endpoints to take my parameters my app needs and query Pivotal's API with my api key and request the data that I needed. Once I had my endpoints setup in the manner I needed I was able to create a static webpage with my javascript contacting my endpoints for what I needed. I did need to configure the Azure function to support cross origin requests. Originally I wanted to place this page on our internal network on a shared development webserver but the lack of the hostname and dependency on cross origin requests was a little too annoying to deal with.

Considering the costs I was not sure how much the Azure Functions would really be saving me. This would be a webpage that is loaded over and over again by a metric dashboard that we have in our team area. I would not be doing any additional logic sending transmitted data into another place. I just needed to query data and render a graph showing our progress. Thus I began to explore implementing an app service. The app service is more self contained and I used the preview of the App Service Editor to build my application from the ground up. I am still struggling to manage my costs and determine if things I have created previously are incurring me additional costs when I do not turn them off. I can see the drill down in my account settings but it is not clear sometimes why what service is charged what amount.

What I liked about the App Service Editor was that it was all very self-contained and had everything that I needed to get my application going. Git was integrated and I did not have to type actual git commands. I was able to npm install the dependencies that I needed and I found resources online how to get started quickly.

In my app I have a public folder where static assets are stored. In the wwwroot folder I have some configuration files Azure uses. An IISNode.yml file where I can toggle on or off logging.

loggingEnabled: false
devErrorsEnabled: false

This was helpful for debugging my routes on the fly and making sure that my api endpoints receive the right data. I also had a web.config file setup to communicate with the iisnode module to provide finer grain control over the webserver requests. Most of my webserver experience is with Apache and its ini based file but modifying xml is not a dramatic change. The boilerplate web.config that Azure has worked for me the only change I made was to redirect http requests to https. There is also a watchedFiles parameter that allows rebooting the server as files change. This made my development quick and I did not need to setup some kind of extra task runners to do this work. Finally in my server.js file I went with restify to setup the routes I needed and made minor modifications to support transferring the nearly identical azure function I had defined before.

While this was not as light weight as the azure functions I still do not have to manage the environment which is a huge win for me. I also have a little more fine grain control versus the azure functions. I can modify this to have some type of state in the future and support other endpoints. I will continue to refine this as long as in the end I can keep the costs down.

Ultimately it looks like for now that I am going back to Azure functions since executions are free under a million per month. If I can get iisnode installed on the dev server or setup some other c# app I may go that route.