Environment variables in Azure Functions with Java

It is often desirable to extract out secret information from source code for security reasons. This allows code to be published to source code repos without accidentally providing credentials to other developers. This can be achieved simply by using environment variables, both when running Azure Functions locally, and when deploying your functions to Azure.

To easily set environment variables when running Azure Functions locally, you may choose to add these variables to the local.settings.json file. If one is not present in the root directory of your function project, feel free to create one. Here is what the file should look like:

Each key / value mapping in the values map will be made available at runtime as an environment variable, accessible by calling System.getenv("<keyname>"), for example, System.getenv("AzureWebJobsStorage"). Adding additional key / value pairs is accepted and recommended practice.

Note: If this approach is taken, be sure to consider whether adding the local.settings.json file to your repository ignore file, so that it is not committed.

With your code now depending on these environment variables, you can log in to the Azure Portal to set the same key / value pairs in your function app settings, so that your code functions equivalently when testing locally and when deployed to Azure. Here’s a screenshot for reference:

Serverless programming makes development of web services and triggers really easy, even for people who are not skilled server-side developers! If you are a Java developer, you should definitely take a look at Azure Functions today – get started with the free tier and go from there! As I noted in my first post – the cost of operating these services is extremely minimal (cents per month).

Creating custom routes in Azure Functions

I’ve been working on my URL shortener project recently, but I took a few days away from it to start writing some JavaDoc for the Java APIs for Azure Functions. In doing so I learned about a cool piece of API that might not be readily apparent (although I hope it is now that I’ve written documentation!), and so in this blog post I wanted to quickly introduce the route field on the @HttpTrigger annotation.

By default, when you create a function for an HTTP trigger the function is addressable with a route of the form http://<yourapp>.azurewebsites.net/api/<functionname>. This is fine in many cases, but in some cases you want your endpoint to be parameterised. For example, we’ve all seen URLs such as reddit.com/r/java, where the java can be replaced by any value (I hope I’m not shattering illusions for anyone by informing you that these all aren’t separate HTML pages sitting on a server 🙂 ). Doing this with Azure Functions is trivial, with help from the route property. For example, we could specify a route of products/{category:alpha}/{id:int}, and this would mean that the function is now addressable at http://<yourapp>.azurewebsites.net/api/products/electronics/357.

If the only benefit was that the path was parameterised, we wouldn’t bother using this API, which is why the other half of the feature is the ability to use the @BindingName annotation to bring in these arguments into the function. For example, here is a full method signature with route and @BindingName in use (apologies for the odd line wrapping required):

As can be seen here, we are receiving the category and id values from the URL endpoint and they are being provided to us as arguments into the function itself, where they are immediately usable. The route string can be quite complex, as there are a number of configuration options available. Microsoft has published useful documentation on routing (just ignore the C# noise 🙂 ).

This has just been a quick blog post on the routing support in Azure Functions, because I thought it was neat. I will keep posting this short snippets as I discover API that delights me. As always though: playing with Azure Functions is really fun – I recommend all Java developers take it for a spin to see what they can achieve when they don’t need to worry about all the underlying infrastructure. Even better, you can get started with the free tier where you have 1,000,000 free function calls a month, and go from there! If you want more inspiration, check out my series on URL shorteners, built using Java and Azure Functions.

Building a serverless url shortener with Azure Functions and Java, part one

I’m a Java engineer who doesn’t really know the intricacies of cloud development as well as my ‘Cloud Developer Advocate‘ job title suggests that I should. That is why I’m such a fan of Azure Functions – it makes the concept of serverless programming a possibility for Java developers. Serverless is one of those odd marketing terms, but what it essentially boils down to, as my colleague Jeremy Likness likes to say, is that it is ‘less server’ – which sounds perfect for me! 🙂

To better understand Azure Functions, I set out to build a URL shortener app, so that I could take a long URL like http://docs.microsoft.com/en-us/java/azure/ and replace it with a short url like http://java.ms/docs. I’m not the first Microsoft Cloud Developer Advocate to do this, as it seems like one of those projects people like to do when they first encounter serverless programming 🙂 You can read Jeremy’s blog about how he built a URL shortener in C# (he’s put a lot more hours into features than me, so there is a lot of good ideas there to borrow 🙂 ).

This is a first post in a series. I’ll add links here when I publish new articles, but you can always follow me on Twitter to keep updated. The total topic list for this series includes:

Serverless Value Proposition

The main attraction to building a link shortener using serverless programming is that you only pay for the time your function is actually operating – you aren’t paying for 24/7/365 server uptime, which is pretty handy for a link shortener that only operates occasionally. You also don’t need to worry at all about concerns such as scaling your service – the cloud provider takes care of that for you. I wanted to build this as cheaply as possible (i.e. consume as few resources, and use the cheapest options) in Microsoft Azure, and I didn’t want to have to write code in any language other than Java, and I really didn’t want to have to worry about all that other cloud nonsense 🙂

In terms of actual costs, Jeremy stated in his blog post the following:

Although actual results will differ for everyone, in my experience, running the site for a week while generating around 1,000 requests per day resulted in a massive seven cent U.S.D. charge to my bill. I don’t think I’ll have any problem affording this!

He also updated his calculations for cost in a follow-up tweet:

I tend to agree – I think I can afford this serverless lifestyle! 🙂 So, off I set on my adventure… I started by buying two domain names – jogil.es and java.ms – which both seemed relevant to my interests. After that, I started writing code (and note: this project is all open source on GitHub)! 🙂 Let’s get into it…

Creating a Java Function App

Setting up a new Azure Function App is simple, especially with the Java / Maven tooling that is available. Firstly though, if you don’t have an Azure account, you can create one for free, and it comes with 1,000,000 Azure Function calls free per month forever (which is well in excess of what I need, so I don’t think I’ll even be spending 7 cents)! Once you have an account, you can follow the Azure Functions on Java tutorial to step through the software setup and creating your own function app. The approach works really smoothly – it’s all based around a few Maven commands that will auto-generate your first function, and you even use this to deploy to Azure! Because of this, I’m not going to dive any more deeply into getting started with Azure Functions with Java, and I’m just going to dive into some of the configuration details, and then into the code for building a link shortener.

Once you’ve done your first mvn clean package azure-functions:deploy, you can log in to the Azure Portal to see your function app, which will look something like this:

In here you’ll see a list of your functions in the left column (my app has four functions: frontend, keepAlive, redirect, and shortcode, as well as details on the URL, subscription, etc. Today we will just discuss the redirect and shortcode functions, and address the other two functions in another blog post.

By default, to access any of your functions, you simply take the base URL (in the image above, it is https://jogiles-short-url.azurewebsites.net), add /api/, and then the function name. For example, the redirect function is at http://jogiles-short-url.azurewebsites.net/api/redirect (and, low-and-behold, if you go there with a given shortcode, it should work – try http://jogiles-short-url.azurewebsites.net/api/redirect?shortcode=docs). As noted at the beginning of this post, the final URL is http://java.ms/docs, but that is achieved using an Azure Functions Proxy, which simply redirects to the full URL shown here. We will return to proxy configuration in a later blog post, to achieve this nicer URL effect.

URL Shortening Function

The key requirement of a URL shortener is to take a URL and return a shorter URL. In terms of implementation, it’s quite simple really – take a url query parameter that we want to convert, use some algorithm to create a unique short code, and store it in some persistent storage. That is basically what you see in the code below, with one additional feature: the shortcode function also supports an optional shortcode parameter. If the user specifies a preferred shortcode (like ‘docs’ above), we simply store that mapping in the persistent storage without running the shortcode algorithm. Here’s essentially the full code listing (remember all the code is on GitHub):

As can be seen, at present there is no authentication, so anyone can create shortlinks (I might rectify this some day soon) 🙂 We simply check the url is valid, and if the user wants an auto-generated shortcode or if they want to provide their own. Based on this, we go in to one of two functions. In the auto-generated case, we iterate until we find an acceptable shortcode, and then we persist that into the data store.

In terms of data storage, I’ve written a small wrapper API around the Azure Storage APIs for Java, as I originally intended to use MySQL or SQL Server (with or without JPA), but then I realised that because Azure Functions are built on top of Azure App Service, which has built-in storage available to it. Because of this, I simply piggy-back on the table store that is already available, using the Java APIs explained in the Azure Table Storage guide. I’ve written a simple AzureTableStore class to handle the read / write access to this table:

The end result of all this code is that I have a table that shows all mappings. Here is a screenshot of the excellent (and free) Microsoft Azure Storage Explorer app, looking at my table of short codes (click the image for a larger version):

You can see I simply use the first letter of the RowKey as the PartitionKey, to have an even distribution in all partition buckets. You can also see that of the four short links I have created, two are ‘custom’ shortlinks (for docs and linkedin), and two are auto-generated (00 and zC). To generate the short links, I simply have the following code I use:

Again, it’s not the prettiest or best approach, but it’ll do for now 🙂

The end result of all this code is that a short code is generated, and a short url is returned, including the URL (that is, java.ms or jogil.es, depending on which host was called to shrink the URL in the first place). That’s great, but it is only half the story – now we need to support the user actually going to that URL and it being converted to the long URL again!

Shortcode Redirection Function

The code to convert a shortcode into a full URL is even simpler, it simply gets the shortcode query parameter, looks up the long url in the data store, and does a HTTP 302 redirect to that URL (302 is the status code for a permanent redirect, as opposed to 301 which is temporary, and will therefore put more strain on the function for people who repeatedly visit the same URL). Here’s the redirect function class in full:

The only odd code is the line where I retrieve the url by calling Util.trackDependency(..). This code is simply convenience code that allows for me to more easily track application performance using Azure Application Insights, which I will cover in more detail in another blog. However, here’s the complete function listing, to make it clear that all that really is happening is we’re calling the data store to get the long url, and we’re recording how long it takes into Application Insights:


This is the core of the URL shortener, but there is a lot more still to cover, which I will cover in follow-up posts in the coming weeks. The total topic list for this series includes:

The main point for this post is that even though I’m not super-skilled in cloud development I was able to implement a simple application that provides a useful service to me, and at an extremely low cost. As I noted at the beginning, the cost to operate this service is mere cents per month! So, if you are a Java developer looking to build web services and don’t want to get bogged down in dealing with server details, you should definitely take a look at Azure Functions today – get started with the free tier and go from there!

Java desktop links of the week, March 12

Howdy folks! Big news this week, so let’s just get into it.

  • The big news this week was the announcement by Oracle that JavaFX is to be removed from the JDK from 11 onwards. This was covered in InfoWorld, and in a blog post and white paper by Oracle. In addition to JavaFX being moved to a module that is not shipped with the JDK, there were other Java client announcements made at the same time: Java Web Start and Applet technologies will also be removed from JDK 11 and future releases, and Swing / AWT, being a part of the Java SE spec, will continue to be supported through to 2026. For those of you forgetting the new release plan, JDK 11 is scheduled for release in September of this year. I have received a huge number of emails from people wondering what this means for JavaFX. The answer is – it is now in the hands of the community, with companies like Gluon stepping up to take on the load. You can choose to look at this optimistically (faster releases, easier contributions from community, etc) or cynically (another area that Oracle has abandoned and left the community in charge) – for me, I will write a blog post adding more detail about this as soon as possible.
  • Eric Canull has posted code to GitHub for a JavaFX-based sorting animation app.
  • Pedro Duque Vieira has updated his FXRibbon project to clean up API, etc.
  • Christoph Nahr has posted about Windows GUI DPI scaling in 2018.