UPDATE: My slides and a protected instance (will open up for play soon) or swinger, available here
We’re at the dawn of a new age on the web, or maybe or horizon, or a precipice; the metaphor doesn’t matter, the point is, things are changing. Specifically, as browsers become more and more powerful, as developers we’re given new opportunities to rethink how we architect web applications. Whether or not some of the predictions of ‘the death of the traditional desktop’ are correct – whether or not the near future desktop is just the browser – we now have the power, without proprietary technologies (flash, etc) to create truly desktop like experiences on the web. Thats nothing mind-blowing, we’ve seen it coming for a little while now.
Ok, then: let me blow your mind.
Here we have a traditional stack. The ‘power’ of the application lies on the server: our development platform of choice (Rails, PHP, etc) sits on top of our database of choice (probably relational, probably SQL). This server platform renders finished HTML and maybe decorates those pages with the use of our JS library and our application specific code (Your $(hit)). In this model we’re using probably at least 3 different programming languages and almost fully on the speed and reliability of our servers for getting data to the user. There’s probably also at least 3 steps in either direction between data and the user:
- User clicks a link on a page or follows a URL
- The request is sent to the server
- App receives request passes it on to Model/ORM layer
- ORM requests the data from the Database
- Database returns the data to the ORM
- ORM returns the data in a parse-able form to the App
- App converts it into user-readable format and displays it to user
Obviously, Rails and most other languages frameworks abstract a lot of this away, so we don’t really have to think in all these steps. They’re there, though.
- User clicks a link on the page or follows a URL
- Data is requested via AJAX from the server
- The server proxies to the database or processes the request directly
- The data is returned to Sammy.js as JSON
- Sammy.js uses the data it needs and displays it to the user
One of the provisions I gave for my talk is that “I’m less concerned with speed than awesomeness”. That rings pretty true here. I don’t have an architecture like this running in production and getting hit like twitter. I can’t really speak yet to how well it ‘scales’ or how it preforms under load. I CAN tell you about how awesome it is and how easy and fun it was to develop swinger with Sammy. That’s really all I need to know right now.