Now that the pendulum is slowly swinging back towards classic plain HTML web servers, we can also simplify our authentication strategies. It's time to go old school again, and build a plain old ASP.NET MVC site using server side razor as our view engine. It's going to contain a very basic set of pages, and navigation links that change based on whether the user is logged in or not. We're going to use Supabase Auth to handle all the actual identity management, as well as providing us with the E-Mail verification functionality.

Writing fable bindings is easier than many people think it is, but still require a time investment depending on how much of the API of a Javascript/Typescript library you want to expose. Having a Typescript definitions file will give you a very big advantage as you can see exactly what types a function expects and returns, without implementation details getting in the way. Additionally, there is the ts2fable project, which attempts to automagically type out everything in the definitions file. This is usually a good starting point. The official fable documentation is a good resource, and one of the resources I used to learn how to write bindings.

This is my entry for the F# Advent Calendar 2021. Thank you Sergey Tihon for organizing it. This post will explore building a small demo application using the Sutil framework. See the final result here.

This is a continuation of my previous blog post about real-time communication with Giraffe and Fabulous. Reading the other article is not required for this one, as it aims to accomplish the same thing, but using a nice friendly F# wrapper around SignalR. This post is also my entry for the F# advent calendar organized by Sergey Tihon. Once again a huge thanks to Sergey for organizing these every year. Awkwardly, Mark Allibone has also written an article for the advent calendar, which is very similar to my first post. Well, here's hoping we can learn something from each other.

Real-time communication can make any application that much more interactive. Whether it be a simple chat application, or other notifications that are pushed live to the client, there is a significant improvement in the user experience when this information is pushed in real-time to the client without the need for a page refresh, or specifically having to pull this data. In many user facing applications, this is usually accomplished using WebSocket protocol. And in the .Net space, the dominant library for WebSocket support is SignalR. SignalR provides a number of advantages over directly using WebSockets, because it provides several features on top. Some of these features include improved connection management (e.g. how to handle reconnecting), sending messages to all or only some clients, and built-in scaling. Additionally, SignalR can automatically fallback to Server-sent events or Long-Polling depending on what the client supports.

I want to introduce a state machine testing library for .Net called Scrutiny. You can get it from NuGet here. It aims to allow random testing of state machines, with a focus on UI testing, by modeling a state machine as a directed graph and path finding through all possible states.

The Winter 2020 round of the F# mentorship program is now over. I participated as a mentor, and wanted to share my experience. The mentorship program is organized by the F# Software Foundation, and runs twice a year for 6 weeks at a time. All participants are volunteers of the community, and are asked to join the F# slack channel to communicate.

This is my F# Advent Calendar 2019 entry. Last year I wrote about Fable React and Preact, but this year I want to write about data access, a topic that practically any application requires. Considering F# is a .Net language, any of the large amount of ORMs available to C# are also available to F#. The big problem, of course, is that they are generally OOP oriented and not not very idiomatic F#. Now, of course you could argue that, because F# is multi-paradigm, it's not actually a problem switching to OOP, but where would the fun be in that?

I’m slowly building a .Net Core global tool to do some REST API testing. One idea I had for this project was to be able to generate multiple URLs with different variables. e.g. http://www.example.com/?id={{INT}} would generate several URLs with the {{INT}} part replaced with randomly generated integers. The solution that I came up with for this, was to use regular expressions. {{(.*?)}} is the regex I came up with to find all parts enclosed by double brackets.

This is my entry for the F# Advent Calendar 2018. I’ve been doing full-stack .Net web development for ~6 years now, and I learned F# ~3 years ago. In the second set of 3 years, I’ve also done more frontend web development than I did backend. In this time I’ve had the (mis)fortune of playing with countless JS SPA frameworks. This has given me the insight into what these various frameworks do, how they work, and how they differ from the other frameworks. I’ve also thought about what web developers should be paying more attention to, and what is nice and fun. In this post I want to explore a combination of what’s fun (Fable Elmish), and what I believe developers need to pay more attention to (bundle size). With that, I’d like to delve into two topics, namely, what I believe to be a big problem with the current state of web development, and a possible solution to this problem.

I ran into an interesting problem recently. The task was to search for something within a SQLite database by comparing strings. Generally very easy to do in just SQL using the UPPER function:

There was recently a project I was working on that required a recursive call. The problem was, that the function returned an async workflow, and in my inexperience, I was running into the problem that I didn’t know what each exit point should return exactly. This is a problem, because in F# all code paths must return the same type, and I wasn’t sure when I needed to wait for an async call, or return the async workflow itself. The idea behind the function was that it would query the database for a specific string, and if it didn’t find anything, it would shorten the string and try again, until the string was a certain length. After some looking around online, I came across this FSSnip that describes a recusive async function:

I’ve been working on a dotnet core global tool. One of the things that such a tool has, is many command line options. I found Argu to parse these command line options. However I ran into the problem that I was left with a very large amount of if/else statements. Perhaps I don’t know what the “proper” way is of handling this, but this was my naive approach.