Invalidation (request to repaint) on demand functionality change
Prior to this update, parts of the code that needed the display would request that the display updates itself with an invalidate command – something other old Delphi custom control writers would probably recognise. This was starting to become inefficient, and while I tried a few different ways of improving the performance – you know like using setTimeout and clearTimeout to prevent lots of redraws nothing really worked out.

The draw operation is now done in an setInterval callback which is set to fire every 40ms (basically equating to 25fps for draw). Yes, I know that all of you smarty pants out there will say this was obviously the way to go, but for some reason I thought I could implement an on-demand drawing system better (that maxed out at a 25fps draw rate). Anyway, lesson learned – the animation loop is in and it’s working really well.

Essentially, the invalidate command still exists and is used to inform a SLICK.Graphics.View (api doc to come) that something is actively requiring redraws (such as a panning or pinch zoom operation). That just triggers a flag that means we need to lay off heavy buffer redraws while this is going on.

Created a ViewLayer “class” in addition to View
Prior to this refactoring, the tiling and mapping classes extended the functionality contained in the View. However, things were starting to be come a little unwieldy and seperate drawing operations weren’t terribly well encapsulated. As such I introduced a ViewLayer to serve as a mechanism for encapsulating that draw code. Essentially, a ViewLayer has a z-index and can be buffered or unbuffered (i.e. it draws directly to the View canvas as opposed to an offscreen buffer, which is then drawn across). Since creating the ViewLayer class I have been able to encapsulate nicely a Radar Overlay, a cross hair Overlay, copyright text for the maps, etc and most importantly been able to implement zooming behaviour for the maps in a way that provides the experience that we are all used to (I’ll post more on this later). Anyway, I’m very happy with the result and if anyone want to checkout the code – feel free to have a look on Github. The following modules are probably of most interest:

• http://github.com/sidelab/slick/blob/master/src/js/graphics.js
• http://github.com/sidelab/slick/blob/master/src/js/tiling.js
• http://github.com/sidelab/slick/blob/master/src/js/mapping/ui.js

Right, onto implementing the RouteOverlay to enable displaying a route on a map…

Any questions, comments, etc, then feel free to leave something below or comment over on Github (I think you can do that)…

As someone who is passionate about cross platform mobile development when it came time to build a mapping application, I believed very strongly this could be done using cross-platform, web-based techniques. Additionally, I am complete agreement with http://jonathanstark.com/blog/>Jonathan Stark regarding his take on why you should write cross-platform mobile apps using web techniques. I’d recommend getting his book, BTW. Anyway, I’m getting off track – basically the goal is to write a mapping application in such a way that it could be deployed natively using any of the cross platform mobile frameworks out there. So what tools do you have to do that?

Well, I guess let’s start with what we do have. For the user interface we can probably choose either jQTouch or iUI (or Sencha Touch if you are currently* writing an opensource app). When the dust clears from Sencha’s unveiling I may try and do a comparison of the pros and cons of each of these, but not now – suffice to say they will all do the job quite nicely.

So, we got some UI elements, what else do we need – oooh I know, a map! Well mapping APIs are pretty much written in javascript so they should all work right, well, yes, kind of, but at the same time no. The current suite of javascript mapping toolkits are very much geared towards mouse driven interfaces and don’t really cater for touch interfaces (i.e. no pinch and zoom). And while I did hack around with javascript API of the deCarta mapping platform that is being used by my current client, it really didn’t cut the mustard. Why not? Well primarily, because the majority of those older API’s have had to cater for a lot of older browsers and to their credit they have done very impressive things to get online maps to where they are today – but it’s time to cut out the fat.

Enter SLICK
http://github.com/sidelab/slick
Slick was primarily born to create a HTML5 canvas based tiling map layer to meet the needs of the mapping application that I am currently writing. But I don’t like writing things that can only be used for one thing. As such, I’ve tried to nicely abstract and provide useful wrappers for capturing touch events and building sliding tiling interfaces of different kinds. I even started to write some UI components, but I’m going to rip those out because they don’t belong (I might create a SLICK UI lib, but we’ll see how we go).

In the first instance, Slick was very much built on jQuery (and it definitely still relies on it in certain places). I have, however, come to realize (through frustration) that building a dependency in like jQuery is a pretty dangerous thing and a simple thing like the different ways jQuery handles ajax calls between 1.3.2 and 1.4.2 can definitely stuff you around. As such, I am in the process of decoupling reliance on jQuery. I don’t love it any less, it’s just that Slick can’t need it. So what do I miss most about not have jQuery? Selectors – no, I miss them, but I can always integrate Sizzle. Really simple AJAX calls – no, they betrayed me ;( The thing I miss most in not having jQuery is jQuery.extend.

Enter GRUNT
http://github.com/sidelab/grunt
I need an extend mechanism, and while I searched for a javascript library that provided just the core requirements for building a javascript library (extend, ajax, etc) I couldn’t find one anywhere (please let me know if you know of one). As such, I started integrating some of the core useful jQuery stuff into Slick. Then I thought, hang on, I’m just doing what everyone else is doing, so I stopped. I then started removing core modules / functions that I was using from Slick and putting them into a new library that I have called Grunt (it does the Grunt work). The extend mechanism is implemented as per the jQuery one (if any brave souls think they can write a better, one I’d be happy to see the library forked). I’ve also implemented ajax handling from the ground up (which needs quite a bit more work). There’s some XPath wrappers and other stuff, so if you are interested, then have a look.

Use at your own risk
At the moment, both SLICK and GRUNT are very much works in progress. In the areas that I’m using them extensively they are both quite stable, but I expect that people will be able to break them with relative ease in different usage scenarios. If you are feeling brave / bored, however, I would love feedback on either library (GRUNT will likely die if I can find someone who has already invested effort in creating a similar base library). Additionally, once things get a little less busy for me (which is currently looking like sometime in 2012, I hope to put together some demos for Slick showing what it can do).

In the interim, feedback welcome.

Personally I’d love to see a strong Brisbane contingent hit Sydney and put a few teams together to showcase the talent that is kicking around up here, and all for a good cause. There’s definitely a few people that I have in mind, and yes, I’ll probably be hunting you down

Thanks to SquiggleMum for giving me the green light to go and participate in what I think is going to be an awesome experience – just having a look around at flights, it looks like it would be about $100 each way with Virgin Blue. But interested to see what other people can find around the place if we do manage to get a few people together.

Come on, you know you want to – register for the event. If you can’t go to the event, and still feel like making a difference to the world, maybe you should think about sponsoring a child through either Compassion or World Vision (both excellent Child Aid organisations).

Oh, and I forgot to mention, the event is free (thanks to some kind sponsors) with food and drink provided. Now, if you need more than that, you are just being hard to please.

Well, here we go, and just as a side note I’ve flip-flopped between windows and web programming so it’s going to be a mix of both.

Windows: Borland C++ Builder (C++)
Used for windows development. Clunky syntax and a very poor cousin compared to Delphi. It sucked almost as much as I did back then. While we owe a lot to C and C++, I doubt we owe very much to Borland’s variant.

Verdict: Forgettable

Windows: Borland Delphi
Anyone who knows me, knows not to get me started on Delphi. One of the great object-oriented programming languages + supporting toolkits of our time – largely due to the genius of Anders Hejlsberg. Sadly Delphi could never stand up against the momentum of Visual Basic, and has largely disappeared into history. Pity, it was simple to do the simple things and proportionally difficult to do the difficult things – you could even embed ASM if you were feeling ambitious.

Verdict: Unforgettable

Web: Perl
I certainly learned a lot about coding for the web from Perl, and while the language itself is not as popular today as it once was, it’s still pretty solid. As tempting as it is to write that the language is forgettable just to stir up a good friend of mine, Perl has done too much for the web just to belittle it for the sake of my own amusement (it was close though).

Verdict: Unforgettable

Web: Cold Fusion
I have to admit, I’m in two minds with regards to Cold Fusion. It was a language that didn’t really do anything too special out-of-the-box but what you could do was just super simple to do. Additionally, as the product did mature and became a J2EE web app you could do cool things like access java libraries, etc, so that was pretty nifty. Still, I think I could afford to forget…

Verdict: Forgettable

Web: ASP.NET
By rights, DOT.NET should have been the holy grail of web application development for me. The C# language was built by my old Delphi friend – Microsoft wooed him to the dark side and it promised a real re-thinking of application development in general. Somewhere along the way, though it seemed to lose it’s way. I got into ASP.NET at 2.0 and you could do some cool things then, but then Microsoft felt the need to implement AJAX coding in a completely half-baked way and I had flashbacks to the holy wars of Delphi vs Visual Basic. There is no doubt that .NET is a big deal, and I built some pretty good web apps using that technology, but it wasn’t thanks to the patterns and practices promoted by Microsoft. If you are going to code in .NET then I’d recommend checking out a local alt.net group for using the technology effectively.

Verdict: Forgettable

Web: Javascript
To close out the languages that I have coded in professionally, javascript definitely deserves a mention. It’s the poor orphan language that nobody thought would amount to anything but with some talented and outspoken people like John Resig and Douglas Crockford massaging, promoting and educating people how to use it, it’s become one of the great enablers of the modern web application. Honestly, whatever server-side language you decide to use, make sure you skill up in javascript. I’ve never trusted server-side javascript generators and even if you use them you should know what you are dealing with in terms of the code they generate. For some fun, why not check out server-side javascript goodness like node.js or jaxer.

Verdict: Unforgettable or Forget at your peril

The Potential Replacements

Currently I’m using (or looking at) the following languages, and only time will tell whether they will be deemed life-changing and unforgettable, or as Rimmer would say “languages I’ve met” (note: creative license).

• Python (with Django) – unforgettable for speed and general arrogance of the language
• Ruby – never intended to use, but things have a funny way of working out. Jury’s out.
• Groovy – definitely unforgettable – closures I love you. But not more than SquiggleMum – if that were true I’d be a dead man.
• <Insert unforgettable functional programming language here> – preferably not JVM based, suggestions welcome.

Feel free to step in and defend your beloved languages if you feel an injustice has been done, or leave your language baggage in the form of a comment.

This is part 1 of the wrap up from that week – a comparison of the native bridges for cross platform iPhone and Android web app development.

The three candidate frameworks that were compared last week were PhoneGap, RhoMobile and Appcelerator. Each of the products takes a slightly different approach to native device integration, so while all three appear very similar on the surface they do have distinct differences. The right platform for you will largely depend on the style of application you are building and your preferred coding style. Without further ado, let’s take a look at an overview of each of the frameworks. After that, we’ll have a look at which framework I have decided to take forward to develop a mapping application and why.

PhoneGap
phonegap.com
PhoneGap is a native bridging framework in the purest sense. It is an enabler for accessing the native capabilities of a multitude of devices using web technologies as much as possible. You can write web applications with hooks into the native capabilities of the device in your javascript code. Structure your application well and you should be able to support progressive enhancement using those additional native capabilities. Once you have done this, you should very easily be able to make your application available through both the device application stores and online at a url of your choosing.

Choose PhoneGap If…

• You are a writing (or have written) a mobile web application or site and want to access the native application stores and/or the native capabilities on a number of devices.
• You have experience with HTML / CSS / Javascript technologies, and the neither of the differential offerings in Rhodes (Rhomobile) or Titanium (Appcelerator) appeal to you.

Rhodes by Rhomobile
http://rhomobile.com/products/rhodes/
While in my previous post comparing mobile web frameworks I shyed away from Rhodes due to a preference for Python over Ruby, I gave it a more solid shot this time. While it took longer to gain familiarity with the framework due to the extensive use of Ruby and Rails-like architecture, once you get the hang of it you can definitely appreciate some of what Rhomobile are trying to provide you in a mobile application framework.

Whereas PhoneGap take a very bare-bones framework approach to a native bridging framework, Rhodes provides an architecture for building data-driven mobile apps that will be very familiar to developers who are familiar with Rails or similar MVC frameworks. Additionally, Rhomobile provide a number of additional services that can enable you to create a mobile application with supporting data stores without having to look beyond their RhoHub and RhoSync products. While I have a strong preference for using server-side solutions such as AppEngine for providing the remote component pieces of a mobile application, and wiring it all together myself, there are times when using something like RhoHub could definitely be appealing. There are some costs associated with using RhoHub though, so make sure you investigate these before jumping in boots and all.

Choose Rhodes If…

• You have experience with Rails and the Ruby language and are looking to create mobile applications.
• You are interested in created a data-driven mobile application and are looking for a framework that is geared strongly towards supporting those kind of apps.

Titanium Appcelerator
http://www.appcelerator.com/
Titanium is probably one of the most ambitious of the native bridges that I looked at in any sort of depth. Appcelerator’s pitch is slightly different to the other frameworks in that they are pushing to achieve Cross Platform Native Development – both for desktop and mobile operating systems. This is definitely a big task, given the progressive nature of the mobile SDKs especially. With the amount of work that is required to support native controls and application components on a device, Titanium doesn’t yet have the same breadth of device support that both PhoneGap and Rhodes have – currently they support both iPhone and Android, and a Blackberry beta is scheduled for release soon. I don’t consider this a problem right now, as I’m taking quite a blinkered view to cross platform support myself at this stage prioritizing iPhone and Android above all other platforms.

Coding in Titanium is definitely a pleasant experience, as development is done completely with javascript. Additionally, framework components make the task of developing the app quite a straightforward process with a nice UI for starting and logging in your applications while developing. Plus the buzz of seeing a native control created from writing javascript rather than Objective-C feels very good indeed.

Choose Titanium If…

• You really want to develop a cross-platform native mobile application using javascript, rather than Objective-C.
• Are focused primarily on iPhone and Android handsets (and soon Blackberry).

Impacts for a Mapping Application
While I started the week looking for something in one of the frameworks that would differentiate one framework from another for building a mapping application, I didn’t really find one in particular. Both Rhodes and Titanium are pushing the envelope and offer native mapping controls for various platforms (Rhodes does have wider device support currently), both implementations only provide support for displaying a map and pinning annotations on the map at a particular latitude and longitude. Satisfactory for some apps, but I need to go further than that.

Additionally, not suprisingly both frameworks support native maps for Google Maps only out of the box, and the complication I have is that in this instance I need to develop for the deCarta mapping platform (despite my love of other things Google – AppEngine, Android, Wave, etc).

Mobile Web Application Framework of Choice (for me)
Firstly, let me say this was not an easy decision to make, a number of factors contributed to my decision. Based on the evaluation I completed, my experience over the 5 days regarding what could be achieved in each of the frameworks and how, and additionally my understanding of each product’s roadmap moving forwards I will be going with (drum-roll please…): Rhodes. Here’s why:

• Despite not being a Rails user (or avid fan), what was offered through the MVC framework that underpins Rhodes does support the creation of scalable, maintainable cross-platform mobile web applications.
• Titanium provided quite a significant distraction with the access to native controls in their framework, until I sat back and remembered that wasn’t my core focus. Appcelerator are offering mobile cross platform native development, whereas my focus is on mobile cross platform web development. The titanium approach is very appealling right now, but in a couple of years I believe will be less necessary.
• While PhoneGap provides excellent component pieces for bridging a web application to the native capabilities of a device, the Rhodes architecture (once I had the hang of it) offerred a little more.
• Finally, and probably most importantly, I had some conversations with Adam Blum regarding the direction in which they are wanting to take Rhodes and Rhomobile in general. From those conversations, I was able to see some alignment between this application (and future application) goals and their roadmap – which is quite exciting.

Questions? Clarification?
If you have any questions, or if I haven’t provided enough detail on any of the points please feel free to leave a comment below. Additionally, if you are involved with development of either PhoneGap, Rhodes or Titanium and I have missed the mark on anything, please leave a comment below to clarify.

To add an extra layer of complexity I will be doing this using the deCarta Mapping Platform rather than Google Maps, as I’ve had some experience with the deCarta platform in the past and found it to be technically very good.

To get started, here is the rough schedule I have worked out for the week:

Day One and Two – Identify Best Fit for Purpose Cross Platform Toolkit

• High level investigation implementing mapping application in what I believe are the current top three cross-platform mobile frameworks:
  • PhoneGap
  • Appcelelerator
  • Rhomobile

  Basic goal is to have a simple tiling map display implemented using each toolkit. Ideally in the deCarta platform.

• Identify potential barriers for later-stage implementation, and push the boundaries a bit.

Day Three – UI Toolkit Investigation

• Investigate most suitable HTML UI toolkit for implementing a slick UI that behaves itself on both iPhone and Android. Current candidates are:
  • jQTouch
  • iUI

Day Four – Push “Most Promising” Platform
Based on the results of days one to three, push the selected development framework plus supporting mobile web UI (if required – would be of little use in Appcelerator) to try and anticipate future problems that might occur in a cross-platform approach to a mapping application.

Day Five – Compare back against deCarta Native iPhone API
deCarta do have an iPhone API available as a Beta – available from their devzone (registration required). Some comparisons will be done against the general feel of the iPhone native application vs a cross-platform alternative to determine if and where usability is compromised using a cross-platform approach.

I’ll be attempting to post an update of each day / phases results so if you wish to keep up-to-date with progress, please subscribe to the Distractable feed.

Updated Response Time Graphs (1 minute Pingdom Check Interval)

Gaelyk Test App Response Times

Lift Test App Response Times

Python Test App Response Times

Python Test App Response Times Variant (1000ms max y-axis)

Reading the Updated Graphs
As you can see, the graphs this time around are presented slightly differently, with separate graphs for Grails, Lift and Python. Additionally, the graphs shown here showing data from Pingdom after setting a request interval of 1 minute as per Sean Gilligan’s suggestion. On each of the graphs, the line colouring is as follows:

• Red: The average response time for the 450 requests sampled
• Orange: The average response time + 2 standard deviations to help detecting the outliers
• Blue: The actual response time for the sample

So, what do the new graphs show us? Firstly, when doing an apples and apples comparison (see below for more information) with Gaelyk and Lift we can see that Gaelyk actually performs a little better. Whether or not this is going to be the case consistently I cannot say – but we can see that the Lift framework tests are producing loading requests more frequently. In reality, I believe this is a variable factor caused by sharding requests to different JVM instances and running the tests again could quite potentially yield different results.

Secondly, the Python response times still kick the pants off the JVM test apps, but please read on as I try to put some context around this statement as this isn’t an in-depth Python vs Java language performance shootout…

Clearing up a few things
Given some of the comments that I saw on Reddit, YCombinator, etc, I guess I should probably clear a few things up (or at least try):

• The original post wasn’t meant to be an in-depth comparison of language performance on Google AppEngine. Sorry if you felt that the title of the post misrepresented the content. The focus of the post was to demonstrate the impact of the “Loading Requests” on AppEngine – sadly titling the post probably wouldn’t have brought the problem to many people’s attention…
• As I point out in one of my comments on the previous post the original post paints Gaelyk in an undeservedly bad light, as I wasn’t really doing an “apples and apples” comparison between Gaelyk and Lift. The lift test site for the previous site was an established site as opposed to a fledgling. This has been rectified in these tests and I am now using a recently created Hello World Lift Testbed. This is particular important to me because…
• I consider both Groovy and the Gaelyk Groovy AppEngine Framework some of the most elegantly executed pieces of coding that I have seen. Basically, I really like both of them, and because of this I would be very happy if I could create scalable web applications on AppEngine using them.
• My definition of a scalable application, means that it performs as well if it is serving 1,000,000+ as it does if it is serving 1. Usually the challenge is catering for the 1,000,000+, however, with the situation here our application does not scale to a smaller number of users. I’m not sure how to get an application to 1,000,000+ users if it doesn’t perform well for a few.
• I don’t think Python is better than any JVM based language. Right now though it does offer faster baseline response times on AppEngine.

Conclusions
Loading requests are still a problem for JVM based sites / applications hosted on AppEngine. The good news is that the ability to reserve a JVM for your application is on the AppEngine Development Roadmap so hopefully we should see it in an upcoming release soon. Additionally, while not encouraged by the AppEngine team using a cron job or external service such as Pingdom to keep your application alive will help minimize the occurrence of loading requests, but you will have to make sure you are polling once a minute as once every 5 just doesn’t cut the mustard.

If, however, you are a Java/Groovy/Scala/etc user and have gotten to the point where you don’t think you can consider AppEngine for deploying your web site / application there are alternatives. One that was suggested to me was Stax which does look pretty good.

As for me, I’m definitely not at that point – I intend on pushing ahead with AppEngine as there aren’t too many cloud platforms that offer scalability to the point that AppEngine does – but that’s a conversation for another time. Additionally, I intend on trying to build a small tool to help keep your AppSpot application “warm” (despite the appengine’s team’s advice).

If you are interested in getting an update on this tool when it’s finished, or would like to keep in touch with AppEngine and other articles, please subscribe to the Distractable feed.

Update 2009-04-29:
I mentioned Stax as an alternative that is available to AppEngine for Cloud deployed Java apps, and it is probably worth noting that while it isn’t yet available, VMforce looks like a really interesting option too.

I found out about Loading Requests in AppEngine, when I pushed my first Gaelyk application to it’s home on AppEngine. I’ve been keeping an eye on the performance of my sites and applications using Pingdom monitoring, and unfortunately I saw something that made me feel a little sad when I saw the results.

Comparing the performance of my Gaelyk skeleton site (WIP @ sparkz.distractable.net) with my own (pretty rough) Python AppEngine Proxy, the Vosao CMS running the Sidelab site, and the Lift examples on AppEngine you can see that Gaelyk really lags behind in terms of performance.

Update 2010-04-25: As comments around the place have suggested, note that the Scala Lift vs Groovy Gaelyk isn’t really an apples vs apples comparison. In my view this is primarily because I was running tests against the established appspot lift samples. I provided more detail on this in a comment below

Now, I had pretty much decided that I was going to use Groovy and Gaelyk in some future projects, but these loading requests really throw a cat amongst the pigeons. I believe some people are using cron jobs to keep the AppEngine JVM warm and prevent it from unloading, but this practice is discouraged by Google (understandably). Considering also that my pingdom check interval is 5 minutes if it’s unloading between those requests, then I don’t hold much hope until Google do something about this.

To that end, there are a number of things in the pipeline that will probably help things along. The ability to precompile was introduced in AppEngine 1.2.8, and while it does make a difference when you enable it looking at my detailed pingdom logs requests are still taking almost 10 seconds to complete. Additionally, there is an issue worth starring that if implemented will hopefully enable people to reserve a JVM instance. Doing this would bring response times of my very simple Gaelyk app down to around the 250ms time. Hurrah.

In the meantime though, I think I have to seriously consider either going back to Python for AppEngine development or investigate Scala and Lift. Any opinions? I definitely know more people who are passionate about Scala, but really, it’s still JVM based and definitely nowhere near as mature as Python. Excuse me now while I wipe my tears shed for Groovy and Gaelyk away.

While I’m doing that though, here are a couple of other useful resources on the topic:

• http://github.com/garyburd/app-eng-cold-start-test
• Google App Engine Loading Requests Happen Very Frequently @ StackOverflow

Update 2010-04-25: I have posted a follow up to this post in an effort to clear up a few points of confusion. Additionally, it looks at the whether making requests to your site every minute (instead of every 5 minutes) reduces the impact of a loading request.

The latest piece of news that I just received an email about is Appcelerator’s 1.0 release of its Titanium platform, which is obviously a bit of a milestone for the guys over there at Appcelerator.

In conjunction with the 1.0 release, they also announced their professional subscription package for the Titanium platform which is currently being offered at a $199 per developer per month subscription fee (with discounts for annual subscriptions). I’m not sure whether this is priced right, although I can definitely see the serious work that the team at Appcelerator are putting into both building their product and community, and those things don’t come for free. So at some point they do need to generate some revenue if they are going to be a sustainable business – and I hope they achieve this.

I guess from my own perspective as someone who is about to leave the corporate world and start building my own development company (web applications, mobile apps, digital innovation strategy, etc) it just seems a bit more than I could fork out for in the early days. I think $49 per month I would think about, and probably even deal with not getting access to certain extra benefits, but without the big corporate budgets or VC funding the $1699 for a year subscription (per developer) isn’t going to happen in the first year. Remembering, however, the effort that Appcelerator are putting into their community it probably isn’t going to be such a problem anyway – not at least if you are a semi-resourceful kind of individual.

I think with the appearance of a supporting financial model (which admittedly the other players such as PhoneGap and RhoMobile also have – paid training and commercial app licencing arrangements respectively) combined with the obvious ongoing commitment to their product and community development, Appcelerator are quickly establishing themselves as the one to watch. Despite my interest in the myriad of web based mobile frameworks and supporting toolsets out there, if Appcelerator are going to make the task of web standards based mobile development clear and simple, thereby offering a real alternative to native Objective-C development (yuck) on the iPhone I’ll definitely buy (metaphorically at this stage) tickets on that train.

I’ll be building a couple of test applications over the next week or two, so happy to provide updates on my thoughts of the 1.0 release if anyone is interested.

The first of those will be an experiment using Google’s AppEngine as a front-end proxy to a less robust website, hosted on low-cost hosting. Whilst not sure, I’ve got a feeling that I’ll be able to give my self-hosted wordpress blog a layer of resilience with some app-engine mem-caching goodness.

The basic principle behind the idea is to implement a simple site proxy on Google AppEngine and make use of AppEngine’s memcache to provide relief to the rather cheap shared hosting that I currently run this blog on. In this way, should I ever write an extremely compelling post then my blog won’t get smashed by the SlashDot / Digg effect. The diagram below illustrates in very simple terms the relationship between the sites.

So, basically:

• The AppEngine application passes through all GET request through to the parent site, storing a copy of the page in memcache before serving the content back. If the specific url was already memcached then that it is returned from the AppEngine site without a round-trip to the parent server.
• POST requests are result in a cache-clear for the url, then the round-trip to the parent server. Then the request is handled in the same manner as a GET request.
• I’m thinking a plugin for the wordpress site is required, so that when I approve comments using the administration facility (I don’t think this should go through the AppEngine application) the WordPress site can instruct the front-end to clear the cache.

That’s the concept in a nutshell, and as pointed out by Glen Maddern when I mentioned I was thinking about this on Twitter, the same application should be able to act as a front-end layer for sites other than just WordPress Blogs. Static sites would just work. Web applications are likely to be more problematic, which is good, as I’m really not in the business of creating tools to stand up a phishing site easily.

In terms of my own personal setup, I plan to www.distractable.net to the AppEngine application, and leave distractable.net pointing at the shared hosting. I’d probably go the other way around if AppEngine supported naked domains, but it doesn’t.

Would really appreciate any feedback on this idea, including those nice curly situations that are likely to make the whole thing fall in a heap

I’ll make sure I update the post with progress updates on how the coding is going – hopefully, if I can keep the blinkers on, then it should be done in a week or so. The source will be kept at GitHub, so feel free to watch the repo if you like to keep up-to-date that way.

UPDATE 11/01/2010:
Looks like there is already a project that is attempting to use AppEngine in a similar way, but as a downstream proxy for browsing. I am unfortunately not fluent in the native tongue of the maintainer of the project, but if you would like to take a look here is a link to the project:

GAppProxy Project on GoogleCode