Functional webapplicaations using fsharp and suave

Editor's Notes

• #2: Good morning everyone and welcome to this talk about functional programming and web applications. Web applications in the context of this talk is server side web applications, or web apis. You can implement client side applications using a F# project call Fable if you want to, but that is not in scope for this talk. Before I go any further I would like to know a little bit more about you. How many know F#? How many here have used Suave?
• #3: Let me introduce myself. My name is Tomas Jansson and I work as a manager at Bekk Consulting here in Oslo, where I am the practice lead of .NET. Even though my title is manager, it is just a label, I am a developer like most of you I guess and that is what I do most of the time. The customer I work for is in the public sector and we have brought in F# in some of our solutions there. I hope to see a wider adoption in the long run, but it is a long walk a head of us to get there. When I’m not working and not relaxing at home I’m also engaged in the community. I lead the NNUG Group here in Oslo and is also the initator of OsloFSharp which is a subgroup of NNUG for practical reasons which we started about this time last year and already have more than 200 members already. I am a Microsoft MVP and F# enthusiast.
• #4: What is F# and why should you care? Let’s first answer the what part, since that is more concrete and nothing you can argue It started of at Microsoft Research but it is fully open source and it is now the FSharp Foundation that maintains the open-source code repository. F# is a functional first language with it roots in the ML tree of languages that runs on the .NET platforms. That means it runs on both the CLR on Windows and Mono on linux systems. There is work going on to get F# to run on dotnetcore and you can try that out today if you want to. That was what F# is, but why do I like F# and why should you consider it?
• #5: Strong typing  if it compiles it most likely runs Not null  Tony Hoare, who introduced it in algol in the year of 65 I think, called it his billion dollar mistake. It is hard to reason and deal with null, so just not having it is easer. Take a list structure in C#, what does it mean when the list is null? Is it empty or did an error occur. That’s really hard to know without looking through the implementation details. Immutability by default  when things are immutable it is much easier to reason of what the state of something is since nothing can change the state. Every time you need to change something that is immutable you create a new copy instead, It’s not as expensive at it sounds and the syntax support for it makes it as easy as setting a property in C#. Structural equality  this just make sense. When comparing things you actually check what the values are instead of checking by reference which is the default in C#. No matter what you compare in F# it works the same way. This is as long as you use types defined in F# and not doing weird things.
• #6: Composability is one of the most important concepts in F#. Can compose types and functions in an easy manner. Making it easy to from this to…
• #7: This. Terrifying deathstar You can compose things in most languages, but the question is how easy it is to do so and how much noise it introduces. The syntax of F# makes it really easy to compose types from other types, without any boiler plate, it also makes it really easy to write functions and combine functions to form a whole in an easy manner. We will see some of this in the demo later on.
• #8: Feedback in many levels - Amazing eco-system with a lot of open source projects and active community. This is probably one of the things I like the most with F#. Everyone in the community is super smart and really helpful. - The next level of feedback is when you code and use the REPL. The REPL makes really easy to do some fast prototyping and experiments before turning the code into a library, if you wish. - Feedback also comes in the form of testing. I would say that the way you write functional code tend to make it much easier to test, since that is what you do constantly in the the REPL. Converting things you wrote in the REPL to a test for more feedback in the long run is really easy as well.
• #9: But F# and web? #wat?
• #10: I would go as far as to say that all applications are functions! And since web applications are applications they are also functions. What do I mean?
• #11: Most people thing of a web applications like this. You have some kind of client that makes a request to the server and get a response back. This is only a mental model.
• #12: But what if you just change the arrows as a first attempt to change your mental model of a web application.
• #13: When you have done the first step it’s not hard to see that this is exactly what a function is. This brings us to the last part of me just talking and that is.
• #15: It will also run on dotnetcore when all the F#-bits are ready. There is already some bits running on dotnetcore, but I haven’t tried it yet. I have tried it on mono and Windows and the programming experience using Suave hits a sweet spot for me at least. You get a lot of control, and at the same time it is really easy to get started. It is implemented in F# for F# to be a idiomatic functional web framework, compared with for example asp.net which you also can use together with F# if you want to.
• #16: The three most imporntat concepts in Suave according to me are these three. And I will go into a little bit more detail before showing them in practice.
• #17: The context is what holds all the request and response data through a web request. Each request basically starts with a default context and then you create new contexts, remember that F# is immutable, through a series of steps.
• #18: Those steps are WebParts.
• #19: The signature of a webpart looks like this. Which basically reads, take a HttpContext as input, return a async computation that returns either Some of a new HttpContext or None if this WebPart should be skipped.
• #20: This is the glue that glues web parts together.
• #21: This is the glue that glues web parts together.
• #22: This is how it is defined bottom up. You start with a set of functions or values, it could be a function that looks something up in a database, a function that renders html, or something that modifies a header value, ot it could even be a ready WebPart.
• #23: The next step is to apply a combinator to create a WebPart, if you have a function that returns a json object you might use a combinator to create the actual httpcontext from that object.
• #24: If you have multiple endpoints you usually use another combinator to wrap the webparts to create a single webpart. If you then have cross-cutting concerns you migh have additional layers that wrap the last webpart. That is the simplified version of how it works, and that’s basically all there is to it.
• #26: I will be using these two tools as well. Paket for handling packages, which is a package manager for nuget packages FAKE is a build automation system. I won’t go into details about how this two tools work, but please come ask questions afterwards if you have question regarding these two tools. But they are worth looking into even for C# devs.
• #28: Great stricter but yet more flexible language than C# Runs great on all common platforms through clr and mono
• #29: The web is functional, and programming web applications in a functional language can be a new amazing experience where you can combine and put together applications the same way you build lego.
• #30: A great option if you want to program the web in a functional language is F# with Suave.