DEV Community: Eesaa Philips

making fast sites even faster

Eesaa Philips — Wed, 14 Jun 2023 21:05:03 +0000

I began the rewrite of my quiz web app called "et3allim" (which means "learn" in arabic) in solidjs. It was originally written in angular without paying much mind to performance. The goal of this rewrite was to make the site much faster and more responsive. I'm still in the beginning stages but I can already notice a 3.5 times (or 111.11%) difference in page load time. There are three reasons for this.

1. Web Framework

Angular is much slower than solidjs and updates in the UI take longer. I was using lazy loading and other best practices in angular but it just couldn't compete with the performance of solidjs.

2. UI Frameworks

In the older version, I was using bootstrap and material UI. Both have a combined size of 147kb + 90kb = 236kb. This is not small. You could compress it with gzip but it's still a heavy load on your page. Instead, I just didn't use a UI framework and wrote my own css. I did use skeleton css which is 170 bytes only, and just wrote my own css for the styling. This makes the site's css much smaller

3. Hosting

The old site was hosted in a vps (linux server) using digital ocean. This server is located in north america which means if someone opens the site from the other side of the world, the site will take longer to load. Instead, the new site is hosted on cloudflare pages which uses a cdn. They have many servers around the world and will deliver the page from the closest location to you.

A word on solidjs

I have nothing but great things to say about this amazing and minimal framework created by Ryan Carniato. It does everything perfectly, and once you understand the core concepts, you can create extremely fast reactive web apps.

Better error handling in C# with Result types

Eesaa Philips — Sat, 10 Jun 2023 12:52:48 +0000

The Problem

Exceptions are slow, cumbersome, and often result in unexpected behavior. Even the official Microsoft docs tell you to limit your use of exceptions.
Most of the time, you want to handle both the success and failure cases without allowing the exception to propagate. You might be wondering "if I won't use exceptions, how can I tell the caller function that something went wrong?". This is where the result type comes in.

The Result type

When our function needs to represent two states: a happy path and a failure path, we can model it with a generic type Result <T, E> where T represents the value and E represents the error. A function that gets a user could look like this:

public async Result<User, string> FindByEmail(string email) {
    User user = await context.Users.FirstOrDefaultAsync(
        u => EF.Functions.Like(u.Email, $"%{email}%"));
    if(user is null) {
        return "No user found";
    }
    return user;
}

You would call the function like this:

[HttpGet("{email}")]
public async Task<ActionResult<User>> GetByEmail(string email)
{
    if(string.IsNullOrEmpty(email)) {
        return BadRequest("email cannot be empty");
    }
    Result<User, string> result = await FindByEmail(email);
    return result.Match<ActionResult<User>>(
        user => Ok(user),
        _ => NotFound());
}

If you don't want to return strings for errors, but instead a different type, you can define those classes/structs and return them or use the existing Exception types for your errors. Returning exceptions is fine, throwing them is what's costly.

Here is the code for the result type:

public readonly struct Result<T, E> {
        private readonly bool _success;
        public readonly T Value;
        public readonly E Error;

        private Result(T v, E e, bool success)
        {
            Value = v;
            Error = e;
            _success = success;
        }

        public bool IsOk => _success;

        public static Result<T, E> Ok(T v)
        {
            return new(v, default(E), true);
        }

        public static Result<T, E> Err(E e)
        {
            return new(default(T), e, false);
        }

        public static implicit operator Result<T, E>(T v) => new(v, default(E), true);
        public static implicit operator Result<T, E>(E e) => new(default(T), e, false);

        public R Match<R>(
                Func<T, R> success,
                Func<E, R> failure) =>
            _success ? success(Value) : failure(Error);
    }

The implicit operators allow you to return a value or error directly. For example, return "err" can be used instead of return new Result<User, string>.Err("err"). It will automatically convert it to a result type for you.

Performance comparison

I wrote a benchmark that compares returning a result with throwing an exception. The benchmark compares the identical functions if they fail 0% of the time, 30% of the time, 50% of time, and 100% of the time.
Here are the results:

What we care about here is the mean. You can see that returning the result directly and matching outperforms exception handling as exceptions get thrown more often.
In reality, your function will probably not throw exceptions 50% of the time but this is just a benchmark to illustrate how slow exceptions can be if used often.

This is the benchmark code:

    [Params(0, 30, 50, 100)]
    public int failPercent;

    [Benchmark]
    public int[] result() {
        int[] res = new int[100];
        for(int i = 0; i < 100; i++) {
            res[i] = getNum_Res(i < failPercent).Match<int>(
                    n => n + 10,
                    err => 0);
        }
        return res;
    }

    [Benchmark]
    public int[] exception() {
        int[] res = new int[100];
        for(int i = 0; i < 100; i++) {
            try {
                res[i] = getNum_Exception(i < failPercent) + 10;
            }catch(Exception) {
                res[i] = 0;
            }
        }
        return res;
    }

    public Result<int, string> getNum_Res(bool fail) {
        if(fail) {
            return "fail";
        }
        return 1;
    }

    public int getNum_Exception(bool fail) {
        if(fail) {
            throw new Exception("fail");
        }
        return 1;
    }

Closing Thoughts

Throwing less exceptions means writing less lines of code, and handling errors more efficiently. Remember, "The best code, is no code at all". Have a good day :)

From C# to golang: less is more.

Eesaa Philips — Sun, 09 Apr 2023 23:10:39 +0000

I had been writing .NET backend systems for more than 4 years. I've used it at work, side projects, and college projects.

Recently, I decided to use go to build the backend for a mobile app. I value simplicity, and therefore enjoyed go the moment I stepped through go by example

Go prioritizes simplicity and intent. It is imperative and eliminates many complexities that haunt other languages by choosing a small subset of features. If you're coming from C# or java, you may feel confined by this minimal language at first.
But you will quickly realize that go's strength comes from its simplicity.

Things I like

No need for external dependencies

Everything works out of the box. You can build an entire backend with middlewares, services, repositories, database connectors, etc. without ever looking beyond the standard libraries go provides.
In contrast, building a similar system in C# requires external dependencies.

Go is not opinionated

There is no right way of doing things in go. For example, if you want dependency injection, you set it up yourself and pass your services as parameters. Go does not do any DI magic under the hood which makes you mindful of how you create and pass your objects.
Go offers more freedom than C# which can lead a new developer to stumble until they find what works best for them; but I see this as an advantage. It forces you to make deliberate choices about the structure and flow of your code rather than blindly conforming to a predefined structure others have placed for you.
.NET's minimal APIs are the closest you can get to Go in a C# backend. It's a step in the right direction.

Built in testing

When testing in C#, I would usually use an external library like xUnit and another for mocking. In go, testing is built in. You don't need to rely on any 3rd parties to test. You can benchmark, setup before tests, and teardown after tests using the built in testing library.

Less Boilerplate

It takes less code to get a server up and running than C# .NET or java spring. This is a hello world http server in Go:

package main

import (
    "fmt"
    "net/http"
)

func main() {
    http.HandleFunc("/", HelloServer)
    http.ListenAndServe(":8080", nil)
}

func HelloServer(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "Hello, %s!", r.URL.Path[1:])
}

I know a minimal C# API is just as small if not smaller, but most backend C# systems use controllers. A typical C# codebase will likely be much larger and contain more boilerplate compared to go.

Extremely Easy to Learn

You can learn go in a few days and build something with it in no time. The learning curve is far from steep. You just hop in and next thing you know, you're spinning up services in no time. This is also great for hiring: it's easy to get a junior dev on the team and they will be contributing soon after.

Concurrency

Concurrency in C# is complex, especially for new developers. There are many ways to achieve concurrency but equally many caveats and catch22s. You can use Parallel.invoke, Parallel.forEach, Task.WhenAll, Task.WaitAll, and more. With these abstractions, you gain granular control over the task: you can control if it's blocking, configure cancellation, etc. But you also risk running into countless complications. Be careful if you don't want the bloodcurdling deadlock monster entrapping you. example

In go, concurrency is straightforward and untroublesome. you simply use the keyword go to run a function asynchronously. For more control, you can use channels and waitgroups which go provides to allow for fine grained control. Go's goroutines are similar to C# tasks where multiple goroutines map to a small number of OS threads. One of the differences is goroutines contain normal go code while C# tasks need to be written (or potentially re-written) to be asynchronous.

Things I Dislike

Lack of Mature Generics

Generics were recently added to golang but they are not mature. You cannot use generics without instantiation which limits your options. Functionalities that are easily achievable with generics in other languages may require workarounds in go.
Another pertinent issue is the lack of support for union types on struct fields. See this issue.

Lack of Built-in Higher-order functions

Go does not have higher-order functions out of the box. If you're used to using LINQ in C# or streams in Java - which use lazy iterators to filter and process data immutably - you might be disappointed. Technically, you could write functions like these in go using closures. In most cases, the performance and complexity overhead of these custom iterators outweigh the benefits. This is by design. Go is meant to be simple. But I still find myself missing the niceties of LINQ from time to time.

Closing Thoughts

If you noticed, I did not compare performance because it doesn't really matter in this context. You can build very capable and performant systems with C#, go, java, rust, etc. Your performance bottleneck will almost never be one of these languages, but rather your design choices.
I also refrained from complaining about Go's error handling because, although it's not as good as Rust's or C#'s, it's still fine and forces the developer be mindful about handling the errors.

If you haven't already, give golang a try.

None of this really matters; just build something

You can sit here all day arguing about syntax differences and language superiority, but it really doesn't matter. The best programming language is the one you're most productive with. So just go out there and build something. Build it with go, java, or even assembly. Just avoid idle hands.