Today, we launch a new product called Aqueduct, an open-source server-side web framework written in Dart. Why did we choose Dart? Simply put, Dart is built for productivity. And now, so is Aqueduct for Dart.
Updated 3/7/16: We’ve just released Aqueduct 2.0, focusing on tooling, deployment, authorization and database querying with more than 3x the documentation.
At stable|kernel, we’re experts at getting well-architected software up and running fast. We’re in the business of building startups, and this means startups within big companies as well. Because startups and new business units are often pre-revenue or operate on low-margins, often we have to iterate quickly and respond with immediacy to early feedback for any chance at success.
We can’t afford to create a mess. That would create diminishing returns in programmer effort. Likewise, we can’t spend tons of time up front because our teams also have mobile applications to build for our clients. We prefer to work in small, full-stack teams. We also don’t have much time or extra bodies to do some of the ‘second class’ features of building a web server. Documentation is an example of that.
Related: A Server-Side Web Framework Written in Dart (by Filip Hracek)
Getting up to speed fast is critical, so we built Aqueduct for Dart – a template that generates a ready-to-go web server, scripts and tools for running remotely, locally or during tests.
- We have valid configuration for Travis-CI.
- Authentication management.
- Logging.
- An ORM.
- A few typical endpoints.
- Documentation.
All in less than five seconds.
This quick-to-start process is extremely important for learning. It’s easy to get feedback cycles and easy to try something new. On that note, it was important to us to write strong documentation. In addition to the API reference hosted on pub, we have a web page with tutorials and deeper, long-form guides on the major features in Aqueduct.
For long-term success, the structure has to be good and has to be easily compartmentalized. Things should be where folks expect them – both in Aqueduct itself, but also in applications written in Aqueduct. Great care was taken to ensure that classes in Aqueduct are clean. A clean class means it does what you expect and nothing more. It’s got to be named correctly. We hope we did that well. But we also didn’t want to prescribe a specific style or limit evolution. So we leave manholes where we can. We made the framework customizable. You can use bits and pieces of it, and replace other pieces with your own stuff or omit them altogether.
Related: Dart: A Simple, Elegant Language Programmers Will Love
How can Aqueduct for Dart succeed?
Also for long-term success, we need tests. Tests are important, and I mean this. Aqueduct for Dart represents a year of work. There’s very little in terms of design that is the same in Aqueduct from when we first started. You can check out the commit history. Because it changed form so often, the tests were vital. The tests have become more valuable than the code they test; the code can change, but the tests define the framework. There are more than 1,500 expectations in the Aqueduct framework.
So testing is important. We want you to run your tests as often as you save a file, but that means we have to make it easy. Like that automatic Cmd-S we all hit after every line of code we write.
We’ve made it easy to test by having some helpful utilities for writing test code by making sure those tests stay runnable on CI tools and by avoiding boilerplate.
More importantly, APIs you build with Aqueduct will have consumers. And as you know, programmers are critical. It’s our job. When building things, it’s often easy to skimp on documentation. Aqueduct helps by building OpenAPI specifications by reflecting on the code. Having built in features for stuff that we have to do in every web servers – database integration, authentication and logging.
Isolates were really appealing to us. Aqueduct runs on a configurable number of isolates. We can also do all of the other stuff we want to do well. Websockets, TCP and UDP, scripting. Those are all in the standard library. Aqueduct applications can use these features.
Dart was the right language for Aqueduct. For us, it’s a comfortable language: it looks like a better version of Java and works like a better version of Objective-C. Whether you’re an iOS or an Android developer, Dart is a comfortable bridge, and it’s extremely mature and powerful that you wouldn’t be able to build a framework like this in other languages, for example, Swift. Dart was the right language for us, and we hope you take a look at Aqueduct.
Support the Dart community by starring these repos in Github: Aqueduct, Angular 2, and Flutter.
