How I Want to Build (Web) Apps

It all began 18 months ago when I started working on DEV x BOTS and a framework to build GitHub Apps. GitHub Apps are more or less complex web applications that react to webhook events that GitHub sends them. My goal was to create an abstraction around the web server so that developers can exclusively focus on their business logic.

DEV x BOTS

After years of experimenting with automation and developer tools, I am starting DEV x BOTS to create an automation platform for developers. We all have tasks that could just be automated, if that was easier to do.

jdno.devJan David Nose

When playing with the idea for Otterdone, I noticed the need to solve very similar problems. While the business domain is a totally different one, running a web server came with exactly the same challenges.

Designing My Own To-Do App

For years, I’ve searched for the perfect task management system. But after countless experiments and iterations, I’ve decided to take matters into my own hands. Introducing my dream app: Otterdone.

jdno.devJan David Nose

Over the past few months, I tried to take a step back and reflect on the ideal experience that I would like to have when building these applications and businesses.

Principles

The following is a short list of principles that I want to explore when building applications of any kind. These principles reflect my background and experience writing code for two decades now.

Convention over Configuration

Maybe my strongest belief is that conventions are almost always better than configuration. Conventions reduce the infinite breadth of possible solutions to a single well-established and well-tested path. Having one right way to do things makes it possible to build processes and tools around it. Problems can be solved once, with an over-engineered solution, because the solution can be shared and reused by everyone following the same convention. This increases efficiency on the development side.

Automation and Tooling

Convention over Configuration enables us to build better tools to support the development process. A great example of this are generators in Ruby on Rails, which can be used to quickly generate code:

bin/rails generate model Person name:string

This command creates a new file for the Person model, a database migration to create the people table with a name column, and it adds a unit test.

Taking this idea a step further, I believe that in the ideal framework no file is ever created by hand. Instead, we can use tools to describe the high-level goals that we want to achieve and have the computer create the scaffolding based on the conventions that we follow.

Code Generation over Abstractions

DEV x BOTS was an attempt to create very strong abstractions around the implementation details of GitHub Apps. This enabled apps to implement only the core business logic, because the rest of the functionality was hidden inside the framework. This worked well for use cases that the framework supported, but doing anything else led to "fighting the framework".

As I think more about my ideal workflow, I believe that generating code instead of hiding it behind an abstraction is the better way to go. Probably not everything, but especially code that the user wants to customize. HTTP endpoints in a web server and UI components in a web app, for example.

The reason why we typically don't do this is that maintaining libraries is so much simpler. There is only a single source where bugs need to be fixed and features can be added. But if we follow conventions, we can create tools that rewrite and update the generated code for us. This provides the best of both worlds: Users have full control over their codebase, but still benefit from future updates and new releases.

This idea is heavily inspired by projects like microplane, Google's Refaster, and Netflix's rewrite.

Frameworks

These ideas are not new and there are many frameworks that implement some of them. But especially in Rust, I have not found a framework yet that I really like. axum is my usual choice for a web framework due to its ease of use. But it is not opinionated and certainly not a fullstack framework. Rocket is a fullstack framework written in Rust, but I disagree with many of its design decisions. And while development has picked up again, it seemed unmaintained for a few years.

Nothing is more true on the internet than that there is an xkcd comic for any situation. This one fits my current thoughts perfectly:

I can't seem to find what I am looking for in the existing landscape of web frameworks in Rust, so I am very tempted to use the lessons that I have learned over the past year(s) to create my own framework.