Web App Architecture

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Web App Architecture

Adam MacLeod
Hello Happy People of MPUG,

I have recently been hearing suggestions that rendering HTML on the
server side is becoming less relevant as JavaScript MVC (and other)
frameworks are developing.

Personally I feel that having all of the client rendering logic live
inside the browser as a client to an API based server application
seems like a decent way to go. I'm sure no one needs to hear this but
I believe it should allow the front end developers to write client
interaction code independently and the back end developers to focus on
data, security, speed and scalability.

As I see it there will be a MC (model-controller) type back-end that
supplies JSON to a model in a JavaScript MVC framework like
backbone.js, ember.js or what have you. I feel that the existing
Django/RoR type mega-framework is simply too heavy for this new MC
backend. Perhaps one of the micro-frameworks like Flask, Pyramid or
similar might be suitable.

I am extremely interested in hearing people's opinions on the following:

 - Whether this is/will ever be a good idea.
 - The size/scope of applications that this is suitable for (personal
website? small-time start up? buzzword-driven-development? Twitter?)
 - The current best practices regarding this type of architecture.

I guess the real meat of my message comes down to the following:

 - Which back-end would you use in Python for an application written
in this style?

Hoping to hear everyone chip in a few cents to this discussion :)

Cheers!
Adam MacLeod
_______________________________________________
melbourne-pug mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/melbourne-pug
Reply | Threaded
Open this post in threaded view
|

Re: Web App Architecture

Javier Candeira
Hi Adam,

On Sat, Mar 17, 2012 at 6:39 PM, Adam MacLeod <[hidden email]> wrote:

> I have recently been hearing suggestions that rendering HTML on the
> server side is becoming less relevant as JavaScript MVC (and other)
> frameworks are developing.

> As I see it there will be a MC (model-controller) type back-end that
> supplies JSON to a model in a JavaScript MVC framework like
> backbone.js, ember.js or what have you. I feel that the existing
> Django/RoR type mega-framework is simply too heavy for this new MC
> backend. Perhaps one of the micro-frameworks like Flask, Pyramid or
> similar might be suitable.
>
> I am extremely interested in hearing people's opinions on the following:
>
>  - Whether this is/will ever be a good idea.

Using a client-side javascript MVC type of application seems to me a
good idea in at least two cases, and an useful option to consider in a
third case:

- Webapps such as gmail, where the "webpage" ceases to be any
meaningful unit of content. You don't expect your email client to
provide you with a url you can share for every click you do on the
browser window, and the "page" is just an application. To this example
I would add the many drawing, wireframing and other design webapps
that are out there, but also shopping carts and, really, any
transaction-type task where the user has absolutely no expectation
that a given URI will retrieve each of their actions.

- The editing end of many classical "publishing" type web
applications. My favourite example is your typical online newspaper.
From a reader's perspective, each page has its own url, and they are
expected to be persistant, and shareable across sessions, so it makes
sense to render them on the server. So far so good.

Now, see it from the reporters' and editors' side. Since the early
2000, we techy people have been building them more and more
complicated layout editors that allow for loading up modules,
rearranging them on the webpage, etcetera. Think the Django admin on
steroids, client-side, live, creating the complex page views that
readers see. Historically, this was accomplished via DOM manipulation,
with the javascript code creating new divs, hidden fields or css rules
in order to store the data in the page's html. This is how a couple of
big newspapers' CMSs I know of in Spain worked in 2005.

As you see, this state of things conflates the view and the model, and
makes for hairier development. The Javascript MVC frameworks serve to
help separate those two concerns: you store data in the javascript
classes, manipulate it there, talk to the DOM just for displaying it.
For these users, the MVC js frameworks are a solution to an existing
problem, and a way to refactor existing working code.

The people I know who were doing this type of work are now working on
their own, making good money selling CMSs to newspapers all over the
Spanish speaking world. I have just written to them to ask them the
crucial question: "at which point did you stop storing working data in
the DOM and basically built yourself a javascript MVC framework for
the browser window?"

- There is a third requirement profile that may lead you to write your
whole site or application in this style: performance. Recently 37
Signals wrote about their rewrite of Basecamp using a fragment, cache,
and client/side assemble page- build strategy:
http://37signals.com/svn/posts/3112-how-basecamp-next-got-to-be-so-damn-fast-without-using-much-client-side-ui

I don't know how the client-side reassembly of fragments is
implemented, but I remember reading that they used one of the MVC js
frameworks.

>  - The size/scope of applications that this is suitable for (personal
> website? small-time start up? buzzword-driven-development? Twitter?)

I see it more for what types of interaction than for size of project or of team.

I can only speak for myself, but:

- If you asked me to write you a webmail or an image editing app, I
would no doubt write it in a client-side MVC JS framework.
- If tomorrow I were to write a shopping cart or a newspaper layout
widget, there would have to be extremely good reasons for me not to
write it client side.
- I think what Basecamp is doing probably works for them, but I would
only go that way if, after having built my site in the traditional
"server renders html" way, measurements and experiments told me that
all-JS was the only way to go.

>  - The current best practices regarding this type of architecture.

No idea. I too would like to know.

>  - Which back-end would you use in Python for an application written
> in this style?

My first experiment would be to use the same web framework that I
would use for anything else, only doing server-side rendering of data
fragments in json templates. But I am ignorant, and it would be just
an experiment.

However, reprising your question...

> As I see it there will be a MC (model-controller) type back-end that
> supplies JSON to a model in a JavaScript MVC framework like
> backbone.js, ember.js or what have you. I feel that the existing
> Django/RoR type mega-framework is simply too heavy for this new MC
> backend. Perhaps one of the micro-frameworks like Flask, Pyramid or
> similar might be suitable.

Well, Django provides you with a lot of plumbing: an admin interface,
sessions, pluggable apps (great for a newspaper or any other site with
many different "areas"). I think the choice of framework is orthogonal
to the choice of client-side mvc js thingies, or not. For example, you
could write a pluggable shopping cart for Satchmo, make it work
client-side, and it would still make sense within Django. Or whithin
any other type of framework you use.

> Hoping to hear everyone chip in a few cents to this discussion :)

Hoping my answer is useful and promoting of more useful discussion!

J
_______________________________________________
melbourne-pug mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/melbourne-pug
Reply | Threaded
Open this post in threaded view
|

Re: Web App Architecture

Ben Dyer-3
In reply to this post by Adam MacLeod
Hi Adam,

We've given this quite a bit of thought, and seem to have come to the same conclusions as you and Javier. So yeah, we think it's generally a good idea for fairly complex apps, but not so relevant for content sites.

Our original web app — a hosted email marketing platform similar to Campaign Monitor, MailChimp etc but aimed at organisations with more complex requirements — was based on CherryPy with Mako for templates and SQLAlchemy for ORM. We didn't want to go down the monolithic framework path, primarily because I'd worked on a reasonably complex project in Rails a few years earlier and had found I spent all my time trying to work around the restrictions it imposed on me (I'm sure it's much better now; this was pre-1.0 Rails in 2005 or thereabouts).

About two years ago we re-wrote everything from the ground up, switching from EC2 to a dedicated VMware cluster, from MySQL to Postgres, and from server-side templating in the CherryPy web app to an app architected essentially as you describe, with a few separate Tornado processes providing JSON APIs called from client-side JavaScript, and another Tornado process handling things like initial login and real-time notifications (long polling).

This had a few practical advantages for us:
• We were able to unify all data access into a single set of HTTP APIs, used by our web app as well as by customers' applications;
• Navigation/interaction latency is almost eliminated because we're able to intelligently retrieve most data before the customer requests it;
• We're able to support things like live editing and instant display of changes (records created, deleted, modified) among all connected clients without much extra work;
• Since we were already using proper bookmarkable links within the application (originally jquery.address.js but recently HTML5 navigation), it was easy to add more "view state" to the URL, so in fact bookmarkability and browser history navigation *improved* when we switched to an all-AJAX app;
• Separating things into one process per logical unit of functionality made performance tuning, scaling and code deployments much easier.

However, we've also encountered the following general challenges:
• Browser support — we gave up on supporting any IE version prior to 8, not because of non-compliance with standards but because their JavaScript engines are too slow to provide decent performance with the amount of data we're displaying;
• Security — loading everything through AJAX means you need to pass tokens in every single request to avoid XSRF issues (http://stackoverflow.com/a/6075862);
• Staff skill-sets — going down this path means you're doing serious application development in JS, not just adding nifty-but-minor features with a few jQuery calls, so it means either your front-end developers are going to have to take on the whole client-side application, or your back-end developers will need to learn JavaScript (not such a big deal now with Node etc);
• Blocking database queries — not really an issue with CherryPy since each request runs in a separate thread, but in Tornado you really need to keep all requests well under a second since they'll block everything, or set up a thread pool to insulate the Tornado main thread from blocking queries.

To give you some context in terms of the second two questions you asked, our application has six developers: one designer who does HTML, CSS, and presentational JS; a back-end developer who does Python and SQL; two who do everything from SQL to CSS; a customer support guy who also does Python and SQL in support of specific customer requirements; and an infrastructure guy who we share 50% with another company. We support a few hundred users total, with probably 30-40 people logged in at any given time. Many of our users spend the majority of their working days inside our application so ease of use, responsiveness and reliability are really important to us. The other side of our application is public-facing, and runs things like "view online" versions of emails, some basic web forms/landing pages, unsubscribe pages, signup pages, and tracks clicks and opens. That side also uses Tornado and Postgres (as well as a bit of CherryPy), and handles a couple of million requests per day.

If I were to re-write our system from scratch using the tools and techniques available now, as opposed to two years ago, I'd still be using a few Tornado processes on the server side, but I'd structure communications between client and server very differently: rather than our current approach which uses a "REST" (in the sense of "what many people call REST but actually isn't at all") API for everything, I'd create a true REST API for the application's core resources, and then do all of the RPC stuff (which doesn't map neatly to REST) via web sockets. On the client side, I'd still be using underscore.js/jqote2-style templates, but I'd build the application using backbone.js rather than rolling our own. I'd also make much more use of HTML5 storage for longer-term caching.

I'm not going to put myself out there as a source of best practice, but I do have an extensive and painful library of suboptimal practice which I'd be happy to share…

Cheers,
Ben


On 17/03/2012, at 18:39 , Adam MacLeod wrote:

> Hello Happy People of MPUG,
>
> I have recently been hearing suggestions that rendering HTML on the
> server side is becoming less relevant as JavaScript MVC (and other)
> frameworks are developing.
>
> Personally I feel that having all of the client rendering logic live
> inside the browser as a client to an API based server application
> seems like a decent way to go. I'm sure no one needs to hear this but
> I believe it should allow the front end developers to write client
> interaction code independently and the back end developers to focus on
> data, security, speed and scalability.
>
> As I see it there will be a MC (model-controller) type back-end that
> supplies JSON to a model in a JavaScript MVC framework like
> backbone.js, ember.js or what have you. I feel that the existing
> Django/RoR type mega-framework is simply too heavy for this new MC
> backend. Perhaps one of the micro-frameworks like Flask, Pyramid or
> similar might be suitable.
>
> I am extremely interested in hearing people's opinions on the following:
>
> - Whether this is/will ever be a good idea.
> - The size/scope of applications that this is suitable for (personal
> website? small-time start up? buzzword-driven-development? Twitter?)
> - The current best practices regarding this type of architecture.
>
> I guess the real meat of my message comes down to the following:
>
> - Which back-end would you use in Python for an application written
> in this style?
>
> Hoping to hear everyone chip in a few cents to this discussion :)
>
> Cheers!
> Adam MacLeod
_______________________________________________
melbourne-pug mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/melbourne-pug
Reply | Threaded
Open this post in threaded view
|

Re: Web App Architecture

Adam MacLeod
Hey Javier and Ben,

Thanks for your replies, I found them both very informative and reaffirming.

Javier; I believe you are correct about apps that have a URL
expectation. I wonder if there is a nice (maintainable) way to
implement complex URL's using the #! method (EG:
https://twitter.com/#!/Raspberry_Pi). I figure that the time to pull
down all the resources and execute another AJAX call could be quite
extreme.

Thanks for the Backpack input and link, I had a read and am going to
explore further through the HTML5 History API.

Please post an update when you hear from your friends in the CMS
business :) I would love to hear their thoughts on the matter. Do they
ever come to Melbourne? Perhaps they could give a talk at MPUG? :)

Ben; I think there is a lot to be said about integrating your own
components into a framework of sorts and maybe this would be a good
way to experiment/prototype a back end. I guess it depends if you
could use any of the awesome resources available to Django or if you
wanted to have a slim/clean core code base.

As a side note, I'd be interested to hear your thoughts about MySQL
and Postgres? I previously favored MySQL but have been increasingly
supportive of Postgres and would certainly use it these days.

The browser support issue is something I hadn't considered as yet,
depending on your market/reach/demographic all of these techniques
might just be out of reach for the time being =\

Thanks for the contextual insight and explaining how you would evolve
if starting today. Your reply covered the area well and I found it
useful.

Does anyone else have any similar stories to share?

Cheers,
Adam


On Sat, Mar 17, 2012 at 8:12 PM, Ben Dyer <[hidden email]> wrote:

> Hi Adam,
>
> We've given this quite a bit of thought, and seem to have come to the same conclusions as you and Javier. So yeah, we think it's generally a good idea for fairly complex apps, but not so relevant for content sites.
>
> Our original web app — a hosted email marketing platform similar to Campaign Monitor, MailChimp etc but aimed at organisations with more complex requirements — was based on CherryPy with Mako for templates and SQLAlchemy for ORM. We didn't want to go down the monolithic framework path, primarily because I'd worked on a reasonably complex project in Rails a few years earlier and had found I spent all my time trying to work around the restrictions it imposed on me (I'm sure it's much better now; this was pre-1.0 Rails in 2005 or thereabouts).
>
> About two years ago we re-wrote everything from the ground up, switching from EC2 to a dedicated VMware cluster, from MySQL to Postgres, and from server-side templating in the CherryPy web app to an app architected essentially as you describe, with a few separate Tornado processes providing JSON APIs called from client-side JavaScript, and another Tornado process handling things like initial login and real-time notifications (long polling).
>
> This had a few practical advantages for us:
> • We were able to unify all data access into a single set of HTTP APIs, used by our web app as well as by customers' applications;
> • Navigation/interaction latency is almost eliminated because we're able to intelligently retrieve most data before the customer requests it;
> • We're able to support things like live editing and instant display of changes (records created, deleted, modified) among all connected clients without much extra work;
> • Since we were already using proper bookmarkable links within the application (originally jquery.address.js but recently HTML5 navigation), it was easy to add more "view state" to the URL, so in fact bookmarkability and browser history navigation *improved* when we switched to an all-AJAX app;
> • Separating things into one process per logical unit of functionality made performance tuning, scaling and code deployments much easier.
>
> However, we've also encountered the following general challenges:
> • Browser support — we gave up on supporting any IE version prior to 8, not because of non-compliance with standards but because their JavaScript engines are too slow to provide decent performance with the amount of data we're displaying;
> • Security — loading everything through AJAX means you need to pass tokens in every single request to avoid XSRF issues (http://stackoverflow.com/a/6075862);
> • Staff skill-sets — going down this path means you're doing serious application development in JS, not just adding nifty-but-minor features with a few jQuery calls, so it means either your front-end developers are going to have to take on the whole client-side application, or your back-end developers will need to learn JavaScript (not such a big deal now with Node etc);
> • Blocking database queries — not really an issue with CherryPy since each request runs in a separate thread, but in Tornado you really need to keep all requests well under a second since they'll block everything, or set up a thread pool to insulate the Tornado main thread from blocking queries.
>
> To give you some context in terms of the second two questions you asked, our application has six developers: one designer who does HTML, CSS, and presentational JS; a back-end developer who does Python and SQL; two who do everything from SQL to CSS; a customer support guy who also does Python and SQL in support of specific customer requirements; and an infrastructure guy who we share 50% with another company. We support a few hundred users total, with probably 30-40 people logged in at any given time. Many of our users spend the majority of their working days inside our application so ease of use, responsiveness and reliability are really important to us. The other side of our application is public-facing, and runs things like "view online" versions of emails, some basic web forms/landing pages, unsubscribe pages, signup pages, and tracks clicks and opens. That side also uses Tornado and Postgres (as well as a bit of CherryPy), and handles a couple of million requests per day.
>
> If I were to re-write our system from scratch using the tools and techniques available now, as opposed to two years ago, I'd still be using a few Tornado processes on the server side, but I'd structure communications between client and server very differently: rather than our current approach which uses a "REST" (in the sense of "what many people call REST but actually isn't at all") API for everything, I'd create a true REST API for the application's core resources, and then do all of the RPC stuff (which doesn't map neatly to REST) via web sockets. On the client side, I'd still be using underscore.js/jqote2-style templates, but I'd build the application using backbone.js rather than rolling our own. I'd also make much more use of HTML5 storage for longer-term caching.
>
> I'm not going to put myself out there as a source of best practice, but I do have an extensive and painful library of suboptimal practice which I'd be happy to share…
>
> Cheers,
> Ben
>
>
> On 17/03/2012, at 18:39 , Adam MacLeod wrote:
>
>> Hello Happy People of MPUG,
>>
>> I have recently been hearing suggestions that rendering HTML on the
>> server side is becoming less relevant as JavaScript MVC (and other)
>> frameworks are developing.
>>
>> Personally I feel that having all of the client rendering logic live
>> inside the browser as a client to an API based server application
>> seems like a decent way to go. I'm sure no one needs to hear this but
>> I believe it should allow the front end developers to write client
>> interaction code independently and the back end developers to focus on
>> data, security, speed and scalability.
>>
>> As I see it there will be a MC (model-controller) type back-end that
>> supplies JSON to a model in a JavaScript MVC framework like
>> backbone.js, ember.js or what have you. I feel that the existing
>> Django/RoR type mega-framework is simply too heavy for this new MC
>> backend. Perhaps one of the micro-frameworks like Flask, Pyramid or
>> similar might be suitable.
>>
>> I am extremely interested in hearing people's opinions on the following:
>>
>> - Whether this is/will ever be a good idea.
>> - The size/scope of applications that this is suitable for (personal
>> website? small-time start up? buzzword-driven-development? Twitter?)
>> - The current best practices regarding this type of architecture.
>>
>> I guess the real meat of my message comes down to the following:
>>
>> - Which back-end would you use in Python for an application written
>> in this style?
>>
>> Hoping to hear everyone chip in a few cents to this discussion :)
>>
>> Cheers!
>> Adam MacLeod
> _______________________________________________
> melbourne-pug mailing list
> [hidden email]
> http://mail.python.org/mailman/listinfo/melbourne-pug
_______________________________________________
melbourne-pug mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/melbourne-pug
Reply | Threaded
Open this post in threaded view
|

Re: Web App Architecture

Javier Candeira
On Sun, Mar 18, 2012 at 9:40 PM, Adam MacLeod <[hidden email]> wrote:
> Javier; I believe you are correct about apps that have a URL
> expectation. I wonder if there is a nice (maintainable) way to

I was surprised when Ben said his apps were more bookmarkable, not
less, after going to a js framework. Ben: could you explain how that
worked?

> implement complex URL's using the #! method (EG:
> https://twitter.com/#!/Raspberry_Pi). I figure that the time to pull
> down all the resources and execute another AJAX call could be quite
> extreme.

As I understand the Basecamp posts, they do cacheing at each div
level. So if they have to request the whole page, they just do one
async request for the cached (or generated) outer div. But this is
just speculation based on reading their writeups.

> Please post an update when you hear from your friends in the CMS
> business :) I would love to hear their thoughts on the matter. Do they
> ever come to Melbourne? Perhaps they could give a talk at MPUG? :)

They are PHP people, and they work only in Spanish markets so far, so
yes, I wish they could visit, but not likely :(*

Cheers,

J
_______________________________________________
melbourne-pug mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/melbourne-pug
Reply | Threaded
Open this post in threaded view
|

Re: Web App Architecture

Ben Dyer-3
In reply to this post by Adam MacLeod
Adam,

On 18/03/2012, at 21:40 , Adam MacLeod wrote:

> As a side note, I'd be interested to hear your thoughts about MySQL
> and Postgres? I previously favored MySQL but have been increasingly
> supportive of Postgres and would certainly use it these days.

For us the key benefits of Postgres were the vastly more intelligent query planner and higher level of standards compliance. We use a number of fairly complex queries and MySQL's inability to optimise subqueries, limitations in terms of using multiple indexes, and lack of support for partial indexes were causing major performance problems. It'd be possible to denormalise, of course, but then what's the point of using an SQL database at all?

I don't really see any reason to use MySQL for any new projects these days: if you want an SQL database then Postgres is superior in basically every way (even replication, since 9.0); if you just want "a datastore" then the various NoSQL solutions are generally no less reliable, and often more performant.

Cheers,
Ben
_______________________________________________
melbourne-pug mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/melbourne-pug
Reply | Threaded
Open this post in threaded view
|

Re: Web App Architecture

Ben Dyer-3
In reply to this post by Javier Candeira
Javier,

On 18/03/2012, at 22:01 , Javier Candeira wrote:

> I was surprised when Ben said his apps were more bookmarkable, not
> less, after going to a js framework. Ben: could you explain how that
> worked?

We started off using jquery.address.js [1], which provides cross-browser support for page state management using the document fragment identifier (#!/whatever). Right now we're using the much simpler and nicer jquery.pathchange.js [2], which uses HTML5 history where possible, only falling back to the fragment identifier method on IE 6 and 7.

In any case, the idea is that you register a callback which is run whenever the page URL changes, like on page load, when the user clicks forward/back, or when an "internal" link is clicked. This callback function renders whatever section of the app corresponds to that URL, so you can tie whatever view state information you like into page navigation. For us, this meant that in-app search/filtering, which we had always done purely client-side, was able to have unique URLs attached so that history navigation made sense in terms of being able to "cancel" or modify your filter settings by going back to a previous page, as well as being able to bookmark a particular combination of searches/filters for easy access.

Cheers,
Ben


[1]: http://www.asual.com/jquery/address/docs/
[2]: http://www.bcherry.net/playground/sanerhtml5history
_______________________________________________
melbourne-pug mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/melbourne-pug
Reply | Threaded
Open this post in threaded view
|

Re: Web App Architecture

Javier Candeira
On Mon, Mar 19, 2012 at 12:38 AM, Ben Dyer <[hidden email]> wrote:
>> I was surprised when Ben said his apps were more bookmarkable, not
>> less, after going to a js framework. Ben: could you explain how that
>> worked?

> [snip]

> whatever section of the app corresponds to that URL, so you can tie whatever view state information you like into page navigation. For us, this meant that in-app search/filtering, which we had always done purely client-side, was able to have unique URLs attached so that history navigation made sense in terms of being able to "cancel" or modify your filter settings by going back to a previous page, as well as being able to bookmark a particular combination of searches/filters for easy access.

Cool, thanks! A friend of mine was fighting with a search-based
interface a couple of years ago. This would have helped him in terms
of UI responsiveness. Good trick to have in mind, and I would add it
as a fourth reason for going this route.
_______________________________________________
melbourne-pug mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/melbourne-pug
Reply | Threaded
Open this post in threaded view
|

Re: Web App Architecture

rdkls
In reply to this post by Adam MacLeod
Just wanted to say thanks for asking Adam, and appreciated your responses Javier and Ben.
(yes - I would be very interested to hear more from you on such topics Ben)
Reminded me of Couch's "Couch App" - basically serving the app straight from the data store, interfacing with json.
Started me on a Saturday learning spree about interesting new architectures (particularly off your 37signals link Ben).
Thanks guys
Nick

_______________________________________________
melbourne-pug mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/melbourne-pug
dan
Reply | Threaded
Open this post in threaded view
|

Re: Web App Architecture

dan
Although strictly speaking off topic as there's no python in there,
thought this link may be of interest given the "new architectures"
direction this thread has taken:
http://blog.fogcreek.com/the-trello-tech-stack/

cheers,
dan

On 19 March 2012 11:36, Nicholas Doyle <[hidden email]> wrote:

> Just wanted to say thanks for asking Adam, and appreciated your responses
> Javier and Ben.
> (yes - I would be very interested to hear more from you on such topics Ben)
> Reminded me of Couch's "Couch App" - basically serving the app straight from
> the data store, interfacing with json.
> Started me on a Saturday learning spree about interesting new architectures
> (particularly off your 37signals link Ben).
> Thanks guys
> Nick
>
> _______________________________________________
> melbourne-pug mailing list
> [hidden email]
> http://mail.python.org/mailman/listinfo/melbourne-pug
>



--
Peace!
Dan

Homer's Brain: Use reverse psychology.
Homer: Oh, that sounds too complicated.
Homer's Brain: Okay, don't use reverse psychology.
Homer: Okay, I will!
_______________________________________________
melbourne-pug mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/melbourne-pug