Archive for December, 2009

Extreme Web UI Scalability – Part 2

0
885 days
by in Uncategorized

Yesterday I did a massive post about separating HTML layout from user data and then using a JavaScript templating engine to bind up JSON data object which contains user-specific information.  I also talked about setting the HTTP expiration policy on the HTML files and using CDNs to scale out your web tier without lots of additional hardware.

In thinking about the solution a little bit further it occurred to me that this could facilitate a RESTful layout of both HTML and JSON URLs.  Specifically, a sample HTML URL would look like the following:

/account/history

While the corresponding JSON data file would have the following URL:

/account/history.js

Then, through URL rewriting, the JSON file would use the session state identifier in the request to map the a directory on the file system, e.g.:

//account/history.js

which would use hard links to map to the real (but hidden) user directory on the server:

//account/history.js

I know this sounds like way too much overhead, but as I said before, this solution is not mutually exclusive.  You can do this where it makes sense and when you have significant load on certain pages.  Elsewhere you can do your traditional request that goes all the way to the server, hits a database, and renders a page.

The last thought that I had was that the JSON files need not be stored on the file system.  You could simply expose a cluster of CouchDB instances (with appropriate security controls, of course).  The CouchDB instance(s) would be responsible for handling the raw request, mapping the session state to the underling user ID, and then pushing out the appropriate JSON file for the requested view.  In this way, you could potentially index the JSON files and make them queryable if you desire.

Postulating Extreme Web UI Scalability

5
887 days
by in Uncategorized

I’ve been working with CQRS for almost a year.  Ever since I first heard about it, I was immediately convinced that it had the ability to vastly simplify a lot of unnecessary development overhead.  In this particular post, I will not be discussing event sourcing which is often mingled with CQRS.  Instead, I will be focusing on the query side of the equation.

Please note that the ideas contained herein are merely conjectures of what might be rather than any kind of working, concrete implementation.  I’ve thought my way through some aspects and ramifications of implementing what I mention below but new insights will undoubtedly merit additional consideration.  Furthermore the solutions outlined below need not be considered mutually exclusive with more traditional ways of doing things.  There is definitely room to implement portions of what I mention for specific views while doing things in the traditional way in other views.

ViewModel Tables

Several weeks ago I blogged about having one table per view.  Since that time Udi Dahan has mentioned it as well, although independently of my post.  Querying view model tables directly, which comes as a positive consequence of implementing CQRS, enables us to avoid having numerous mapping layers between the database and the view.  Further, it allows us to avoid projecting off of our domain model and keeps the domain model focused solely on behavior.  Lastly, it allows us to scale the read database independently of the write database.

Content Delivery Networks

Think for a moment about the pure static resources that are handled on a given website.  They just sit there with the exact same content for each request.  These are the exact kinds of resources for which we could leverage a content-delivery network.  In other words, we could push these static elements to a CDN and have the CDN deliver them for us thus offloading  traffic from our servers and freeing our web tier to perform more interesting tasks—such as processing update-type commands.  Not only does this offload work from our web tier, but the user has a better and faster browsing experience.

HTML + JSON

In ASP.NET as well as other server-based page-rendering technologies we typically have the request come all the way to our server and then we render some HTML but with a few modifications depending upon the user.  Could there be a way to somehow render static layout HTML but render the parts that vary separately?  Why not have the pages render identical static HTML regardless of user and then, on a separate request, render the user-specific content and then stitch the two together using JavaScript?

Let me say that another way.  Our MVC view or our ASP.NET “Page” could render pure HTML with absolutely no server-side markup.  Inside of that HTML we would have the URL of an embedded resource: .  The request to this embedded resource would call our MVC controller and then render JSON data with user-specific information for the currently logged-in user for that view.  We could then use a client-side JavaScript templating engine such as jTemplates to combine the JSON with the static HTML.

Static HTML Views + CDNs

The above has some interesting ramifications.  Why couldn’t we just put the static HTML for each view into an HTML file and push those HTML files to a CDN?  The static HTML files would have

Go to Top