Guest post by Monster Simon Timms
My good friend Simon Timms (not Tibbs) reached out to me on the first day of this series and said, “I’d love to write a post on Functions using F#”. I said that sounded like a fantastic idea, and now here we are. (Well, here I am, with his post. He’s on a beach…)
This article is part of an ongoing series on Azure Functions.
Thanks Thanks to James for letting me guest author on his blog. I love functions and I love F# so this was a fun post to write.
Psst…thanks back at you Simon! Great post and honoured you offered to write it as an addition to the series!
Azure functions can be written directly in a wide variety of languages:
You can also build an executable which can run on Windows and upload it to the function to be executed. This approach allows for maximum compatibility with most any workload you can throw at it. Of all the natively supported languages I think F# fits most nicely into the functional mold.
Of course you can write your functions in C# and everything will be fine but wouldn’t you rather write them in a functional programming language?
F# isn’t perhaps a pure functional programming language but it is close enough to have some great advantages over C#. Declarations are immutable by default, the syntax is terse and stylish, null exceptions are all but unheard of and it has fantastic support for filter which are useful when dealing with any sort of complex data. It is a natively supported language on Azure Functions so let’s see how that works.
You can start with a new Azure function but instead of selecting C# let’s take F#. For our example we’ll base it off of the HTTP Triggered function.
In our scenario we’d like to pull back the headlines from the BBC World Service in JSON format. This, as it turns out, is pretty easy to do in F# thanks to type providers.
A type provider is a compile-time shim which can be used to generate types from a variety of different data sources. The FSharp.Data project includes providers for such things as CSV, XML, Json and databases among other data sources. You can read more about it at their website. We can start our project by adding a new file to the solution, a project.json. This will allow downloading and including libraries from nuget.
Our project needs the type provider and also a handy Json serializer. We’ll include the latest FSharp.Data and Newtonsoft.Json:
Once you save that file you should see a restore started by the functions runtime. This will download and stage your libraries.
Now onto the actual F#. Start by opening the run.fsx file anc clearing it out. We’ll need to include the libraries we’ve just downloaded form nuget
With all our libraries properly referenced we can pull the definition of the BBC’s RSS feed into a type. Remember this will be done at compiles time so you don’t have access to runtime variables like settings in the environment.
As simply as that we now have a type called RSS which is generated from the BBC’s RSS feed. This could have been any feed or format, the XmlProvider just downloads the file and infers the schema.
Now the meat of the problem, download the feed, get the titles and convert them into Json
This code downloads the RSS feed, logs out the title then maps out the item titles and returns it as a Json serialized array. If you’re new to F# you might have noticed that we don’t explicitly return anything. F# will implicitly return the last line of your function.
At the time of writing the output of this function looks like
Of course the F# used here isn’t very idiomatic. Let’s clear it up a bit
With that we have an Azure Function written in a functional programming language. 20 lines all told,including blank lines.
- Day 1: How to organize types in your Azure Function scripts
- Day 2: How to resize an image uploaded to Azure Blog Storage
- Day 3: How to "fan out" work so your Functions can scale
- Day 4: How to deploy to Azure Functions using GitHub
- Day 4.5: Writing Azure Functions in F# Guest Post by Simon Timms
- Day 5: How to import third-party libraries (Up Next!)