Reasons for Thin-Server Architecture

This is a short description of how I am using TSA to help my clients rebuild their web applications to become more flexible and to be built quicker.

I recently started working with a new client in Stockholm who needed to revamp their administrative dashboard for their customers (it's an ad network company). Currently they have a fairly classical Struts application which rebuilds the whole page on every click. The dashboard is very graph and chart intensive, whose graphics had been created by JFreeChart on the server.

The first things I would like to comment on here is the time it takes to make changes. Any change to any file results in a 15s. restart of the local Tomcat to see that it doesn't break anything immediately, and then the built WAR is ssh'ed over to the live system (where the large databases reside, which are not to be used for development but which is needed to see any non-trivial results), which takes about a minute. yes it's slow. Yes, I know. But that's the way it is.

Sometimes you have to restart the server on that side as well when hot deploy doesn't work properly, but that's life. It doesn't happen very often. However, just to see how a change looks on the server takes at least two minutes, possibly more, and that's not a long time, really. it's just that it breaks the concentration of the programmer.

What I did was to arrange with the person responsible for the Struts application (which, incidentally was both smarter and cooler than I was, having done quite a lot of server, demo scene and mobile coding and understood or clarified everything I came up with to talk about, something I really like and don't get enough of. Really :) and managed to get a couple of actions from the server which only returned XML. Naturally we talked a bit of the content, but it was fairly quickly sorted out.

Then I copied the output
of each action and saved to a local file under a directory I called "mock-server". The I made a custom Dojo widget for each action, to massage and dress up the data as need be, which used "Ajax" to read the file from the local directory instead, but which used a parameters to set the url, so it would be simple to change when in production.

The point I'm being very long-winded in making, is that I can now make any number of changes to my widget, using real(ish) data, without breaking my concentration. Also, local page reloads are about as fast as you get when it comes to turn-around time.

What happened at the same time was that there was no way that changes to the server, a reboot of the dev environment, et.c. would bother me in the least. Also, any changes I doodle with locally have no impact on any testing going on, _and_ we just agreed upon a protocol to use, instead of an API, which is much more flexible.

Consider that one of their customers would like to use the data that we use to create Grid tables directly and pipe it into their SOA framework. Go ahead. it's already there. And it took us all of fifteen minutes to agree upon and document it. We have also separated the View from the rest of the logic and put the View on the client (in the browser), which makes things *snappy*.

One of the components was a customized Dojo grid with some formatters for pictures and links, and the other was a fairly large wrapper for several types of chart (You have to look up the Charting API examples in Dojo 1.x, they're simply stunning), and all I get from the Struts server is XML. So I just shrunk the server a bit.

The next step is to remove all JSP processing _except_ the XML feeds (which will use authentication, naturally. Doh!) from the server, which will let the server-side guy concentrate on business logic only, and make the client less magical, being only a bunch of JavaScript and CSS files.. and ONE html file.

One.

What happens here is that you get separation of concerns at a very basic and natural level, you get quicker coding for at least parts of the system, and you get a authenticated XML feed of the most important data in the system, ready to pour into an enterprise bus or what have you.

Anyway I have a gazillion other things to juggle before falling asleep, Just two quick points;

1) If you're in Sweden, don't forget next Web Monday the 1st of April!
2) I'm going to Google I/O 28/29 May in San Fransisco! Yay!!!! :) Possible with the whole family as well. If you're going to be there, drop me a line and well meet up for a beer.

Comments

Anonymous said…
the "mock-server" is a great idea! How did you simulate or test cases where your client needed to send data TO the server?

Come to think of it, I'm not sure I understand how that would work with the real Thin Server. I can see how your client can request data from the server (using the REST url which triggers the JSON/XML/SOAP/etc reply) but how do you update attributes or upload data to the server?
Script Uncle said…
@gswimmer: You are absolutely right that I can hardly simulate the server on the client. In practice, though, way above 50% of all things I do are formatting data sent from the server.

So my point here is more that it makes more sense to use a model where you develop stuff quicker at least 50% of the time, instead of 0%.

I could of course argue that the separation of concerns in and of itself makes development simpler and less error-prone, even if you had a 100% saturation of functionality that updates the server, in whatever fashion.

Cheers,
PS
Simon said…
This comment has been removed by the author.
Simon said…
Hi Peter,

Well done - I couldn't agree more with the advantages. I also use TSA/Serverless AJAX/SOFEA/SOUI and have a consumer product out (APPLEBOX) that uses this same approach with a SOA, SOAP backend. You can read about it on my blog here: here

[edited from previous post]

Cheers
Script Uncle said…
@simon: That's really cool! I like it a lot, but you're just using this internally. Do you have any plans on whitelabeling the platform? Or maybe you have and I couldn't find it out.

Cheers,
PS
Simon said…
I would love to white label it .. there's a good amount of work in it that would save others from retreading the same path. However time is my enemy at the moment. I've bootstrapped APPLEBOX and am flat out getting the business off the ground. Once things settle down I'd love to refashion the framework as an extension to dojo or ext.js and offer it to others.
Unknown said…
Peter,
I would be very interested in joining your Thin Server Architecture group. I work on JavaScriptMVC which supports this specific purpose. Please let me know if this is possible: justin at jupiter dot com. Thanks!
Script Uncle said…
@justin:
I can't seem to get you email address to work. Are you sure that's it?

You can mail me directly at psvensson@gmail.com

Cheers,
PS