It takes 30-40mins to build gcc, so I am blogging in the mean time while I wait. I have come to the conclusion that all Modern Web Applications should general be based on SOA. While I know this is not a new concept, I don’t see it being done by enough people to feel comfortable that people get it, or truly value the power it provides. I made a digram to visualize it in a non-technical manner.

Modern Web Applications

The UI

Okay, so lets start from the UI Layer and work are way down into the application. When building an application in this manner, I find myself building the UI and Middleware in tandem so as not to get bored with one or the other. I will build the UI on something like KnockoutJS since it supports the MVVM pattern which is really my current favorite.

For the User Interface I always build the entire app as one giant ViewModel so as to give us a application state that we can easily serialize and bounce around from client to client. If your user is in the middle of typing a status update and exits the browser to jump on the iPad, the login and see the message they started typing on the screen they just left off, yes, its just that beautiful.

When building out the KnockoutJS, like the website suggests, DON’T BE AFRAID OF BUILDING YOUR OWN CUSTOM BINDINGS. If you are too scared to do so, you will end up trying to build a mountain out of a mole hill, if you are building a Rube Goldberg machine, then it is okay.

Middle-earth … ugh, I mean “ware”

Using something like Socket.io, we can integrate the UI and Middleware Layers together easily and with very little effort. Adding the right transports gives you a degradable and Cross-Browser compliant system, major points to Socket.io for this one.

I typically make the middleware do a limited number of things:

  1. Handle User Authentication
  2. Handle User Authorization
  3. Handle Misc Non-Blocking Operations

So, the first two are a given, these have to be done synchronously with the user. The third one is more application specific. That is, there are certain tasks that do not be distributed yet do need to be fault tolerant, I put there here so that I can alert the user easily and instantly if what action the just took went awry. 

Don’t Punch the Work Horse In the Mouth

Whoa. With tools like Resque and Redis or NodeJS/Coffee-resque this is ready to go almost out of the box. All you have to do is build the tasks you need done. What is great about this is you can either set callbacks or tasks in tasks to schedule other tasks, therefore giving you synchronous operations with concurrency available otherwise.

Building out tasks can be tricky, you don’t want tasks to be over complicated or you will have a large number of failed jobs and issues with plunging your work queue. Smaller, simpler tasks will always result in better performance in my observations. Complex tasks can bring down a worker or even get in the way of throughput for other jobs. That is just evil.

Just to give special note to the”Realtime Push Task”, this tasks pushes system messages back to the UI for the ViewModel to process. Building it this way instead of in the Middleware Layer will give you better scalability in the elasticity sense.

Final Toughts

In closing to this blurb of nonsensical musing of software. I don’t think every app needs to be built this way. If you are building a simple To-Do list, then its probably not the best approach, unless in Rails, then its easy enough to-do … heh. Or even in NodeJS its easy enough. So really its your call. Let me know if you have any questions, class dismissed.

Related Links

KnockoutJS
Resque
Socket.io
Redis

  1. therpeterson posted this