Creating a ServerSentEventServer with ReactiveWebServer

Recently, I am working on a toy project named ReactiveWebServer. It is an event-driven web server built with Rx.

Here’s a simple web server returning “Hello World”.

using (var ws = new WebServer("http://*:8080/"))
{
    const string responseBody = "Hello World";

    ws.GET("/")
        .Subscribe(ctx => ctx.Respond(responseBody));

    Console.ReadLine();
}

The code is simple, but there is nothing new compared to other web servers such as NancyFx.

The real power of ReactiveWebServer comes from its ability to handle streaming data. For example, here’s a ServerSentEvent server implementation streaming integers every second.

using (var ws = new WebServer("http://*:8000/"))
{
    ws.GET("/events").Subscribe(ctx =>
    {
        var obs = Observable.Interval(TimeSpan.FromSeconds(1))
            .Select(t => new ServerSentEvent(t.ToString()));

        ctx.Respond(new ServerSentEventsResponse(obs));
    });

    Console.ReadLine();
}

Data streaming is made simple and easy. You just need to create an instance of IObservable<ServerSentEvents>, wrap it with ServerSentEventsResponse, and pass the result to ctx.Respond method.

Rx RetryWithDelay extension method

Rx provides Observable.Retry which repeats the source observable sequence until it successfully terminates.

Observable.Retry is a useful combinator, but it is a bit limited when retrying an I/O request. For example, when retrying a network request, we should wait a few seconds before sending a new request.

Here is an implementation of Observable.RetryWithDelay which repeats the source observable with delay.

    public static class ObservableExtensions
    {
        public static IObservable<T> RetryWithDelay<T>(this IObservable<T> source, TimeSpan timeSpan)
        {
            if (source == null)
                throw new ArgumentNullException("source");
            if (timeSpan < TimeSpan.Zero)
                throw new ArgumentOutOfRangeException("timeSpan");
            if (timeSpan == TimeSpan.Zero)
                return source.Retry();

            return source.Catch(Observable.Timer(timeSpan).SelectMany(_ => source).Retry());
        }
    }

After validating arguments, Observable.RetryWithDelay create a new observable sequence by concatenating the following two observables:

  • Observable.Timer(timeSpan)
  • source

SelectMany is used to concatenate these two observable sequences. Observable.Timer(timeSpan) has a single value that fires after timeSpan. SelectMany ignores this value and returns source. Then it repeats the result sequence with Retry.

  • Observable.Timer(timeSpan).SelectMany(_ => source).Retry()

This is the next observable sequence we want to continue when source is terminated by an exception. Catch swallows the exception thrown by source and continues with the next observable.

  • source.Catch(Observable.Timer(timeSpan).SelectMany(_ => source).Retry())

Array Typing Problem in C# (and Java)

In this article, I am going to take a look at array typing problem in C# (and Java).

Before we delve into the details of array typing, let’s look at how we declare an array in C#. An array of T elements is written in T[]. For example, you can declare an array of string as in the following:

string[] strs = new string[] { "hello", "world" };

We can pass this string array around to methods which take an argument of type string[]. For example, we call call Sort method to sort the given strings lexicographically.

static void Sort(string[] strs)
{
   // ...
}

But what if we also want to sort an array of ints? Then we need to create an overloaded method which takes an argument of type int[].

static void Sort(int[] ints)
{
   // ...
}

This code smells bad because we duplicate the exact same code except for the argument type. Of course, we have generics (aka, parametric polymorphism) to solve this problem! However, back in the days before C# 2 or Java 5, there was no generics available and the language designers (James Gosling and Anders Hejlsberg) must solve the problem without generics.

Their choice is to make the array type covariant on its element type. To put it another way, S[] is a subtype of T[] if S is a subtype of T. So string[] is a subtype of object[] because string is a subtype of object. This seems to solve the problem nicely because now we can pass an array of string to a method which takes an argument of type object[]. We don’t redundantly need to duplicate the same code for each argument type.

static void Sort(object[] objs)
{
   // ...
}

string[] strs = new string[] { "hello", "world" };
Sort(strs);

Mission completed? No, there is no free lunch in the world. What about the following code?

static void BadMethod(object[] objs)
{
   objs[0] = new object();
}

string[] strs = new string[] { "hello", "world" };
BadMethod(strs);

Create a console application and try this by yourself. Calling BadMethod with strs throws a System.ArrayTypeMismatchException because C# can’t assign an object instance to an array of strings. This is an example of Liskov substitution principle violation. string[] is a subtype of object[], but it behaves unexpectedly when used where object[] is required.

Fortunately, this at least does not violate the security of .NET runtime. We can’t compromise the runtime by disguising the actual element type. However, we no longer can trust that C# compiler will prevent this kind of problem. By making the array type covariant on its element type, we lost static type safety.

Because C# 2 and Java 5 introduced generics to the languages, we have generics in our hands. So technically we no longer need to make this kind of compromise. However, we can’t fix it now because the change will break the backward compatibility. It’s too late.

Forbidden words

There are many scary sounding terms in functional programming. These terms include: “currying”, “homomorphism”, “existential quantification”, “beta reduction”, “category theory”, “algebraic data type”, “Kleisli arrows”, “Curry–Howard correspondence”, “functor”, “applicative”, “monoid” and “monad”. Most functional programming tutorials try to explain what these terms mean as precisely as possible using even more scary looking mathematical notations.

But what about object oriented programming? OOP also includes many scary sounding terms such as “inheritance polymorphism”, “covariance”, “visitor pattern”, “SOLID”. If we explain what these terms mean as precisely as possible, we encounter the exact same situation as FP. Novice programmers would think that OOP is something very scary.

I recently read the articles of F# for fun and profit. Scott Wlaschin explains functional programming concepts without using any of these scary sounding terms. He even has the list of forbidden words. He especially tries hard to avoid the use of words beginning with letter “m”.

I think this is a good approach. Many programmers are interested in functional programming these days. C# programmers want to learn F# and Java programmers want to learn Scala. But they definitely do not want to learn lambda calculus or category theory from the beginning just to learn a new programming language.

Step by step implementation of Option type in C#

Option type is widely used in functional programming languages such as Haskell, F# and Scala. It is conventional to return an option value if a function can fail. For example, the following parseInt parses the given string into an integer. Because parseInt can fail when the input string is malformed, it returns int option instead of int. The return value is either Some(i) or None.

let parseInt intStr =
    try
        let i = System.Int32.Parse intStr
        Some(i)
    with _ -> None

The caller of the function must perform pattern matching on the option value and handle both cases explicitly.

let parseIntWithDefault v def = 
    match parseInt v with
    | Some i -> i
    | None -> def

C# does not provide an Option type, but we can emulate it with the help of C# generics and delegates. Let’s start with the abstract base class Option.

    public abstract class Option<T>
    {
        public abstract T Value { get; }
        public abstract bool IsSome { get; }
        public abstract bool IsNone { get; }
    }

Value property returns the underlying value of type T. IsSome and IsNone properties return a boolean flag to indicate whether this value is Some or None.

Option has two subclasses: Some and None. Both classes are sealed because we don’t want these classes to be extended. This is how we cruelly emulate algebraic data type in C#.

    public sealed class None<T> : Option<T>
    {
        public override T Value
        {
            get { throw new System.NotSupportedException("There is no value"); }
        }

        public override bool IsSome { get { return false; } }
        public override bool IsNone { get { return true; } }
    }

    public sealed class Some<T> : Option<T>
    {
        private T value;

        public Some(T value)
        {
            if (value == null)
            {
                throw new System.ArgumentNullException("value", "Some value was null, use None instead");
            }

            this.value = value;
        }

        public override T Value { get { return value; } }
        public override bool IsSome { get { return true; } }
        public override bool IsNone { get { return false; } }
    }

The implementation is trivial. Value property of None throws an exception because there is no value to return. The constructor of Some throws an exception when the input parameter is null because Some is never null.

The caller can use Option type as in the following:

var v = new Some<int>(0);
if (v.IsSome)
    System.Console.WriteLine(v.Value);
else
    System.Console.WriteLine("None");

This code looks okay at first, but we’ve just lost the power of pattern matching. We no longer can force the caller to handle both Some and None cases. The caller can easily ignore to check IsSome property and just retrieve the underlying value with Value property.

To fix this problem, let’s emulate pattern matching in C# with Match method.

    public abstract class Option<T>
    {
        // Other methods ...
        public abstract TResult Match<TResult>(Func<T, TResult> someFunc, Func<TResult> noneFunc);
    }

Match takes two delegates which handle each case respectively.

    public sealed class None<T> : Option<T>
    {
        // Other methods ...
        public override TResult Match<TResult>(Func<T, TResult> someFunc, Func<TResult> noneFunc)
        {
            return noneFunc();
        }
    }

    public sealed class Some<T> : Option<T>
    {
        // Other methods ...
        public override TResult Match<TResult>(Func<T, TResult> someFunc, Func<TResult> noneFunc)
        {
            return someFunc(value);
        }
    }

With Match method, the caller must pass delegates to handle both Some and None cases explicitly.

var v = new Some<int>(0);
var str = v.Match(
    v  => v.ToString(),
    () => "None"
);
Console.WriteLine(str);

Other methods of Option such as Fold and Map can be easily added. See Option.cs for the full source code with Map method added.

This is just a proof-of-concept implementation. Please refer to Functional C# if you are looking for a full featured functional programming library for C#.