A big driver for And Bang was that it was all supposed to be "glowingly" realtime. Many apps that have some sort of "realtime" component have it sort of "tacked-on" to a more traditional request/response based infrastructure. We wanted the whole experience and the whole technology stack to be realtime.
When I first started tinkering around with building a team task tool a few years ago, I grabbed a set of what were my familiar tools at the time. Django, MySQL and a bit of jQuery.
As it turned out, if you want to build a highly interactive, multi-user, realtime application, Django or Rails and relational databases are not necessarily the right tools for the job.
We quickly realized that we needed to find and learn, or create, a new set of tools to solve the types of problems this presented.
You can trace our progress and experiments a bit by reading past blog posts on the process of finding or building those tools up until we finally launched 1.0 a year ago.
When we launched at last year's Realtime Conference. We had something that worked. It worked really well, in fact. The amount of maintenance we've had to do has been minimal and the tool has become a part of the daily workflow for quite a few happy customers.
We accomplished our goal of making a highly synchronized, completely realtime app. Everything is synchronized. Even when you upload a new avatar your teammates will see it change live as soon as it's uploaded.
Although we're proud of, and excited about, what we built for 1.0, something about it didn't feel quite right to us. As we went on to start building more features, we kept hitting roadblocks. For example:
-
It wasn't very extensible.
-
It was hard for people on our team to contribute to. The whole system was too complex and required too much knowledge of the whole stack in order to feel confident touching any of it.
-
The server code and application data was very tightly coupled to the presentation of the data in the app.
-
In fact, in order to get this "full stack eventing" that we wanted, everything was quite tightly coupled.
-
It was difficult to visualize or manage the data.
-
It was hard to build alternate interfaces or native apps.
So, after doing some initial iterations on the launched 1.0 version we did some soul searching. We still didn't have this ideal realtime platform that we wanted. Being the nerds and tinkerers that we are, we went back to the drawing board.
The core lesson
If I had to pick the biggest, most valuable lesson we learned from this whole experience, it is something that every computer science professor in the world could probably have told us:
SEPARATION OF CONCERNS!
Unless your goal is to build a completely decentralized system where each node is a server and a client I'd suggest following a few simple rules:
-
Servers are for data
-
Clients are for presentation
-
Don't mix
Divide and conquer
To illustrate my point, instead of a single respository that contained the entire AndBang 1.0 application. We now have the following codebases:
- andbang-spec
The single purpose of this repo is to describe the functionality of the API — in intense detail.
- accounts.andbang.com
The application that does oauth and account managment. This is where you log in to manage the teams you're on, etc.
- api.andbang.com
The API. It speaks nothing but data. It doesn't know even how to render HTML.
- docs.andbang.com
It's entire purpose is to document and demonstrate the API. And yet it doesn't actually contains any details about it. Instead it consumes a JSON spec that the API serves that describes its own capabilities. The docs app just renders it into a nice application you can use to explore the capabilities exposed.
- andbang.com
The "official" desktop web client. But it's just that, a client built on the public API. It doesn't contain any non-public information or get any special access. Any one of our customers will be capable of building something like this this without requesting any special access.
- andbang-iphone
Yup. Another "official" client. This time for iOS.
- andbang.js
The "drop-in" JS sdk that andbang.com uses to talk to the API. This is generated from consuming the andbang-spec.
- andbang-express-auth
Drop in oauth middleware. If you happen to want to build an express.js app on our API. It makes the OAuth piece ridiculously simple.
So, we went from a single repository that did everything. To eight distinct codebases.
We'll have a bunch of other posts that go into more detail about the various items above.
Why this matters
Obviously, seperation of concerns is not a new concept by any means. However, when surveying the landscape of people who are wanting to build fully realtime apps I'm seeing tight coupling of frontends to backends and interfaces to data structures.
Ultimately, what we want is the ability to access our data lots of ways and to build a variety of interesting integrations and clients on it. The fact that it's also "realtime" shouldn't limit that.
Frankly, in today's landscape with a plethora of client platforms building for only desktop web, or iOS, or Android, or tablets is silly. The most interesting services all provide this.
If you want to be able to control your app from Google Glass or the HUD in your car, a tightly coupled desktop web app probably won't cut it.
For more on all of this, see my talk from realtime conf:
RTC 2012 - 13 - Henrik Joreteg from &yet on Vimeo.
Be sure to put yourself on the list for access to AndBang 2.0. Hope you like it!
Add your email to join the And Bang 2.0 private beta invite list: