Where I came from

I’ve started out as a PHP developer, using Zend Framework for a large part of my career. Quite a few years ago my projects started shifting to NodeJS, starting with ExpressJS like many others.

I very quickly switched from raw JavaScript to TypeScript due to the improved DX experience and type safety. With that switch I also looked for a framework back then which not only supported TypeScript better, but also had proper support for async-await. This made me land on Koa at the time.

I did end up using Koa for many years to come and was happy with it. I did never stand completely still though and was always looking if there’s something out there which would offer me better DX. I came across Fastify, Hono, Hapi, and others, but I did not really like any of their architectures more than Koa.

Discovering something new

In the past few years I started working more and more with Rust, and eventually I did write some smaller APIs with Axum. I really enjoyed the way Axum applications were structured and how requests and responses flow, which was unlike anything I had seen in the NodeJS world before.

Both middleware and handlers would always receive a request object and return either a response or any value which can be turned into a response. Handlers also have the option to use extractors to validate and extract certain aspects of a request, instead of working with the raw request object.

On top of that both requests and responses have the concept of extensions. So while NodeJS frameworks drag a “state” object along which always needs to be fully typed, extensions always represent a single typed value.

I knew that there would be very few cases where I could use Rust in my client projects though, as most of them are not proficient in Rust, and thus I’d be the only one being able to maintain it.

The beginning of Taxum

A couple months ago I started prototyping certain aspects of Axum in TypeScript. This quickly became a rats tail, as Axum heavily depended on Tower, which in turn depended on the HTTP crate.

I knew that in order to reproduce the same flow as in Axum, I’d need to implement a similar infrastructure in TypeScript as the HTTP and Tower crate supply, so I got started on that. I used both the crates source and their unit tests as the base for my code and worked out those two, before moving on to writing the actual framework code itself.

Once I got started on the framework though, I noticed certain things do not carry over easily from Rust to TypeScript. I needed quite a few iterations to get to a point which is both type-safe as well as developer friendly.

When it came to routing, I didn’t feel like implementing path matching all on my own, not when there is already a really good candidate out there. I thus ended up using find-my-way for that, even though I only ended up using it for its radix tree.

How Taxum turned out

I finally managed to get Taxum into a state I considered stable enough. I had stopped iterating over the API design and started using a pre-release in a client project. This made me discover a few minor bugs which I fixed over the coming weeks, before I decided to call it good enough for a first stable release.

I’ve been using it several production projects successfully by now, and I feel confident that others might enjoy working with it as well.

I ran some benchmarks along the way, and while it does not outperform the fastest NodeJS frameworks, it’s unnoticeable once I/O operations come into play.

The last task was writing a documentation, which is usually not my strongest ability. While I already had very good docblocks in the code, together with examples, I ended up using Vitepress to write a more comprehensive guide which explains all the fine details.

If you’re interested in the framework, I’d recommend having a look at the website and documentation. Also feel free to watch or star the project on GitHub!