Beans On Cheese On Toast
It’s like Ruby on Rails but with ActionScript – and Beans. and Cheese. and Toast.
OK – there aren’t actually Beans or Cheese or Toast, but it is essentially ActionScript on Rails – delicious stuff piled on top of a flexible platform.
The fundamental principles that guide this architecture are as follows:
State is bad
Rich client systems are all flawed in that they force the developer to manage complex, nested state when in most cases, all they really need to be interested in is routing user gestures to the appropriate behavior. With the right system in place, complex state can emerge, without necessarily being managed by implementors.
The observation is that stateless client/server systems that communicate over HTTP are able to have massive complexity emerge from simple, singular, comprehensible request/response processes.
The theory underlying this system, is that one may be able to replicate the same client/server architecture within the context of a single rich client in order to alleviate many of the problems associated with complex state.
Duplication is bad
We have systems and architectures in the Flash/Flex world today that relegate us to almost copy and paste implementations of one boilerplate after another. If the only difference between a multitude of classes are their names, I say our systems are badly broken. The computer is the appropriate tool for dealing with duplication, humans are not. Let’s help the computer manage boilerplate and duplicate behavior with better architectural trade offs.
Strong typing doesn’t deliver on it’s promises
While this opinion is certainly contentious in some circles, in this architecture, it will be treated as a given. The problems that strong typing attempts to solve are more appropriately solved with better, simpler architectures, and the problems that strong typing introduces are often worse than the cure. I’d rather not get into all the murky details of this debate here, so if you’re interested in hashing it out, Wikipedia is as good a place to start as any.
First thing is routing
One of the fundamental almost hidden features of Ruby on Rails is its routing architecture. The ability to transform simple, human-readable strings or commands into complex, predictable responses without forcing the developer to spend long, tiresome hours writing tedious, fragile glue and wiring code, is nothing short of amazing. This seemingly simple implementation decision is really what makes working with a Rails application such a pleasure.
Second is modeling
Boilerplate, duplicate code is at best tiresome and worst, a fragile place where bugs sneak into an application. While the model layer of a rich client usually does not map exactly to the domain on the server, we should work to minimize the amount of boilerplate required in our client system.
Third is the services
There is always a contentious problem around getting data into and out of a rich client. Formats, processes, patterns. These decisions all come into play. Ideally, our rich client models will speak RESTful HTTP, and integrate most seamlessly with Rails, but also play well with other servers.