Introducing Saturn on Functions

Introducing Saturn on Functions

Introduction

Azure Functions is a service that provides serverless execution model while running code in the cloud. Serverless model is getting more and more popular nowadays, being great solution for building distributed, scalable, event-driven applications. However, those are not the only use cases - compute-on-demand story, automatic, low friction scalability and great pricing model means that Azure Functions can be used to host normal (REST-ish) APIs.

On the other hand, Saturn is new F# web framework that provides flexible, high level model of creating web applications using principles of functional programming and MVC architectural pattern. Main design goals of Saturn includes high level abstractions that lets developers focus on creating business code , and general developer experience.

Saturn on Functions

Today I want to introduce new extension to Saturn that adds ability to easily host Saturn controllers and routers inside Azure Functions HTTP triggers. Saturn is a library built on top of Giraffe and ASP.NET Core which means it can easily integrate with existing .Net ecosystem. HTTP triggers in Azure Functions as one of the input parameters are getting standard HttpRequest object that can be passed into Saturn’s controller or router (and any other HttpHandler).

Computation Expression

To reduce amount of boilerplate required to call any HttpHandler and provide, in Saturn’s spirit, opinionated way of hosting your controllers in Azure Functions we’ve created Saturn.AzureFunctions project that adds new computation expression  -  azureFunction

Example:

let testCntl = controller {
    index (fun ctx -> Controller.text ctx "Hello world")
    show (fun ctx id -> id |> sprintf "Hello world, %s" |> Controller.text ctx)
}
let func log = azureFunction {
    host_prefix "/api"
    use_router testCntl
    logger log
    error_handler customErrorHandler
    not_found_handler customNotFoundHandler
}

azureFunction CE provides set of custom operations that can be used to configure Azure Functions adapter:

  • host_prefix  -  prefix of the routes used by Azure Functions. By default Functions are using /api prefix.
  • use_router  -  plugs HttpHandler that will be used. Setting it is required.
  • logger  -  enables passing TraceWriter into your HttpHandler . It’s passed into your functions by ctx.Items.["TraceWriter"] property. It’s also used for logging error in default error handler.
  • error_handler  -  enables plugging custom error handler for unhandled exceptions.
  • not_found_handler  -  enables plugging custom handler for not matched requests.

Using it together

azureFunction CE is transformed into a function that accepts HttpRequest as an input and returns Task<HttpResponse>  -  something that is understood by Functions runtime, and as such can be easily used in normal Azure Functions endpoint.

For example using azureFunction defined above would look like this:

[<FunctionName("HelloWorld")>]
let helloWorld ([<HttpTrigger(Extensions.Http.AuthorizationLevel.Anonymous, Route = "{route?}")>]req: HttpRequest, log: TraceWriter) =
    func log req

Summary

In this post I’ve presented new way of hosting your Saturn applications - using Azure Functions. As you can see Saturn will provide easy to use, opinionated way to embed Saturn controllers or routers in Azure Functions providing great, alternative way of hosting your web applications. 

Saturn.AzureFunctions is currently still developed - if you’d like to check out current implementation, test it, or provide some feedback feel free to check this PR -  https://github.com/SaturnFramework/Saturn/pull/121

read more

Magic of Saturn controllers

Magic of Saturn controllers

Introduction

Saturn is new F# web framework that implements well know design pattern - MVC - in more functional way. Despite Saturn being fairly young project it’s getting more and more popular among F# community and industrial users. One of the main Saturn’s goals is to create high level abstractions that will enable developers to focus on writing domain, business code instead of focusing on creating correct routing for your application or setting right response headers. One of such abstractions, that I want to talk about today, is controller.

read more

OSS and Community. The Story

OSS and Community. The Story

Disclaimer

Before, we even start - this blog post will be different than others on the page. I usually write about some technical things, sometimes about open source and community based software, but I always try to be rather objective. And this post will be different. It’s totally subjective and personal… because it’s about me, and my story with F# Community.

read more

Reinventing MVC pattern for web programming with F#

Reinventing MVC pattern for web programming with F#

Introduction

A couple of weeks ago, I’ve posted yet-another-controversial-tweet - this time criticizing F# libraries for web programming and saying that “they focus on wrong problem”. In this post I’d like to expand this thought a bit, describe what is, in my opinion, problem with those libraries, and introduce a project that will try to fix those problems.

DISCLAIMER: In the original tweet I’ve mentioned three libraries - Suave, Giraffe, and Freya. First of all, if we were to talk about all major F# web solutions we should also mention WebSharper. Secondly, my experience with Freya and WebSharper is fairly limited - I’ve never used any of them in commercial application - so in this post I won’t talk about them but focus on Suave and Giraffe

DISCLAIMER 2: I really like both Suave and Giraffe - I’ve been using Suave for years in multiple commercial applications and I think it’s really good project. Also I’ve been investigating and testing Giraffe for last couple of months and I also believe it’s good project with a bright future.

read more

Path to Community based Open Source Software

Path to Community based Open Source Software

Introduction

Open Source movement has changed the software development world as much as only few things before. Nowadays, it’s almost impossible to develop any project without using OSS - we can be sure that some parts of our stack are developed in the open - from the libraries we download from the package managers, through runtime, to compilers that we are using. Even most conservative, and not-so-long-time-ago actively hostile to OSS companies are now trying to embrace Open Source development.

But putting code in open by uploading to GitHub, using one of the licenses formally accepted by the Open Source Initiative is just first step. In my opinion, the real value of the Open Source is not just license, and publicly available code (although, those things are also valuable on their own) but rather possible change in governance model, collaboration with Community and embracing “OSS Culture”.

In this post I’ll describe different “stages of enlightenment” that company can go through in its path to the Open Source development model that will bring most value to both company and community.

read more