Today, we launch a new product called Aqueduct,  a server-side web framework written in Google's Dart. Why did we choose Dart? Simply put, Dart is built for productivity.

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- a template that generates a ready-to-go web server, scripts and tools for running remotely, locally or during tests. 

  1. We have valid configuration for Travis-CI.
  2. Authentication management.
  3. Logging.
  4. An ORM.
  5. A few typical endpoints.
  6. 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 proscribe 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 succeed?

Also for long-term success, we need tests. Tests are important, and I mean this. Aqueduct is 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: AqueductAngular 2,  and Flutter.



Follow Joe on Twitter!


About The Author

For the past 16 years, Joe Conway has programmed everything from macOS to Android to iOS. As a former instructor and lead developer at Big Nerd Ranch, he fine-tuned his skills and expertise in overall mobile strategy, specializing in iOS Development. Author of "iOS Programming: The Big Nerd Ranch Guide," an Amazon Best-Seller, Joe quickly made a name for himself in the mobile space. He has worked with Fortune 500 companies, technology start-ups and government entities to build mobile platforms, enhance existing applications and develop mobile strategies. Joe was recently named one of Atlanta Business Chronicle's "People on the Move."