So finally the opportunity arose to do some real world F# at work. Being involved in Enterprise Sofware Development a “real world” coding assignment is more akin to Enterprise FizzBuzz than cool Data Science. A colleague had had earlier success using Giraffe, so I favoured that for this task and this blog post is a charting of my struggles. I needed to create an API to server a specfic type of files and non-functional requirements were that I needed to support an existing deployment pipeline for various environments that currently rely on configuration using appSettings.json as well as logging to Serilog and additionally I need OIDC support to authenticate between services. Finally – of course – I need to store data in old school SQL Server. Ideally, I would have liked to provide a Swagger page which I could point to when I want front-end peeps to RTFM, but that is not supported, so I’ll have to tell them to use the source.
Getting started
In order to get off the ground I installed VS Code with Ionide using the getting started guide. I already had .NET Core 2.0 installed, so I could just use dotnet new to create a F# Giraffe scaffold.
Configuration
In order to set up the correct Identity Server parameters I needed this web site to support configuration, and I already knew I wanted to use bog standard ASP.NET Core configuration (including inheritance – yes, I need it. No it’s not worth the effort to change the circumstances) rather than fancier stuff like yml, the best config markup available. Yes, I could save the world by building a config provider for yml and update all our configs, but today is not that couple of weeks that would take to land a change of that magnitude.
.NET Core 2.0 for n00bs
Oh, yes, I forgot to mention – this is my first outing on .NET Core 2.0, so there are a couple of changes you notice in the hosting and app configuration pipeline. One of them is I don’t know where my configuration is supposed to live. Or rather, it can live where it used to live, in the Startup class, but the startup class is now optional, as you have other calls on the host builder that can let you configure app configuration and logging without needing a startup class. For my purposes that was a no go, I needed to get hold of my configuration somehow, so I created a startup class and created a singleton to hold the complete configuration. This singleton got initialised when the startup class was created. With this I could now configure authentication. This isn’t the nicest way to do things, and I’m open to better ideas, but google had nothing. It was as if I was the first one ever to attempt this, which is partially why I’m writing this down. If I’m wrong, hopefully somebody will give me snark about it so I can update with a corrected version.
Authentication
There is a sample for how to use JwtBearerToken authentication, so I just used my new-found configuration skills to add a layer of usefulness to it. Essentially in the jwtBearerOptions function I get the config singleton from above and I use
configMgr.GetSection("JwtBearerOptions").Bind(cfg);
to bind the configuration file settings to the object and afterwards I set some defaults that I don’t want to be configurable. To my shock, I ran postman and sent a valid token to the claims Giraffe sample endpoint and I got me some claims. Incredibly, it worked.
Database access
I have, in C#, come to enjoy Dapper. No nonsense, you write the queries, you get the data sort of lightweight ORM that is simply enjoyable to use. I found an F# wrapper over Dapper that Just Worked. Asked my config singleton for the connection string and we were off and running. Most enjoyable. There were some gotchas involving querying with GUIDs, which I circumvented by typecasting, as in
WHERE CONVERT(varchar(60), FieldA) = @FieldA
I assume you have to cast in your selects the other way around to query uniqueidentifiers as well. but that’s not the worst thing in the world.
Also, multiple parameters in a map to the F# wrapper means you have to cast the variables to obj before you call the query method.
Map [ "FieldA", fieldA :> obj; "FieldB", fieldB :> obj]
Serving files
I made a tiny hack to serve binaries:
let stream (streamInstance : Stream) : HttpHandler =
fun (next : HttpFunc) (ctx : HttpContext) ->
task {
ctx.Response.Headers.["Content-Type"] <- StringValues("application/pdf")
ctx.Response.Headers.["Content-Length"] <- StringValues(streamInstance.Length.ToString())
do! streamInstance.CopyToAsync(ctx.Response.Body)
return Some ctx
}
Of course, a proper implementation will have some kind of record type or at least tuple to provide the mime type with the stream rather than hardcode it.
Service Locator
I set up the IoC container in my unsuccessful attempt at getting Swashbuckle to document the API. I registered an operation filter I normally use to make Swagger ask for an authorisation header on API operations that require it, and that was a bit fiddly, but not very weird. I just made a module that gets called from the ConfigureServices method in the startup class.
Conclusion
Yes, loads of classes and mutable methods. This really is a mess from an F# perspective. Not a lot of tail recursion and immutability. I put the blame on ASP.NET Core. And also I suck at F#, although I’m trying.. My hope is that once this is done I can revise and do better. No, I can’t show you teh codez, but suffice it to say, it looks a lot like the above sample code.