Why Build Another REST Framework?

To support our primary business of building native mobile applications, we've written a lot of server code. And we've done this in a number of languages - Go, JavaScript, Erlang, C# and Java - all of which we've enjoyed for different reasons. As developers, we know that switching contexts is costly. Aqueduct's intent is to reduce that cost for our team of primarily mobile developers with a framework that feels more like iOS+Swift and Android+Kotlin.

Reducing the cost of context-switching alone isn't everything - we also know a few other things lead to project success.

Consistent Interfaces

As iOS and Android developers, we've been spoiled by tightly integrated, consistent frameworks. Once you've learned how to use these frameworks, you can generally guess how their other features work. This boils down to employing design patterns and naming conventions consistently. Aqueduct strives for this same consistency.

A consistent interface means you don't have to read a lot of conceptual documentation or look on StackOverflow to use a feature of the framework. For example, types with the word 'Controller' in them all serve a similar purpose in Aqueduct. Instead of searching the entire API Reference for a type to use, a developer can filter their search to a subset of types with 'Controller' behavior. This is the same optimization behind traversing a search tree instead of a scanning a list, but for us humans.

Meta-programming

Meta-programming allows us to declare the behavior we want, without necessarily writing all of the code to get that behavior. This is valuable because it reduces both programmer fatigue and mistakes. For common tasks, this is a big productivity boost.

While Aqueduct has many meta-programming features, it doesn't prevent low-level access. Whether that is using the standard Dart library to handle an HTTP request or writing raw SQL, abstractions are there when you need them and can be pushed aside when they get in the way.

Automated Testing

As mobile developers, we know that time is easily lost to broken or inconsistent REST APIs. Using a client application to test the validity of a server application is unproductive. We wanted something better.

Testing is a first-class citizen in Aqueduct; tests are both easy to write and run (locally and in continuous integration tooling). We know that when we write Aqueduct code, we can trust that client development goes smoothly.

Aqueduct itself is well tested, too; we simply can't afford to ship releases that break the applications that we maintain for our clients.

Quick Start and the Learning Curve

The ability to quickly get feedback and explore an idea is key to mastering a skill. Aqueduct's tooling, templates and built-in features make creating, modifying and running a new project very quick.

Speed

We built Aqueduct from the ground up to run on multiple threads without having to write any additional code. Even a programmer that hasn't yet learned the pitfalls of concurrency can reap the speed benefits of multiple CPUs without trouble. Alongside the high performance C/C++ Dart VM, Aqueduct applications deliver on speed.