WebAuthn is a relatively new standard for authenticating users and is an incredibly secure way to authenticate users by being phishing resistant, and not requiring passwords at all. It accomplishes this via public-key cryptography. To read more about it, check out Wikipedia. You can also see which services already support passkeys here.

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.

When learning F#, at some point you'll come across the concept of Railway Oriented Programming (ROP). It's primarily a technique used for error handling and helps alleviate some of the struggles of using only exceptions. The main advantage is that possible error cases are encoded in the type system, which requires you to explicitly handle the possible errors instead of encountering an unexpected exception at runtime. Scott Wlaschin has a great post introducing the concept and use cases of ROP. This is a great read if you're unfamiliar with this style of programming.

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.

Since I bought my own domain, and rent a server to host this blog, I've been meaning to add some kind of analytics. But in the interest of user privacy, and keeping the amount of data loaded by the client to an absolute minimum, I kept putting off adding a well-known analytics solution. I knew from the beginning that I, under no circumstances, want to add Google Analytics. However, I've been wondering about Matomo. The big advantage to Matomo is that it's self hostable and open source, so you can be sure that all data collected is exactly where it should be, and not being sold to further 3rd parties and advertisers. But Matomo is still an extra client side library that needs to be sent to the client, and that goes against my mission of keeping this site to an absolute minimum size.

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?

This is a personal blog where I will write about all my various programming adventures. The majority of the posts will most likely be about F#, as that is my language of choice, and I want to promote it and functional programming in general. However, that's not to say that it will be exclusively about F#, and will also contain other posts detailing my learnings of other languages, frameworks, and tools. I will probably also write about home automation, and any discoveries I make in the process of self hosting various services. At the time of writing, I don't have a tagging system or a Series feature implemented yet, but those are things I plan to do. I will be using those features to allow easy organization and filtering on the various types of posts I plan to write.

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: