³ÉÈËÂÛ̳

« Previous | Main | Next »

The ins and outs of Barlesque

Post categories:

Mat Hampson Mat Hampson | 15:00 UK time, Wednesday, 30 June 2010

In the last few weeks you may have noticed an update to the design of the bbc.co.uk masthead, and I thought it might be interesting to tell everyone a bit more about how we're able to go about making a change like that across the entire site.

The reason this is complex (and therefore interesting) is because bbc.co.uk has been going a long time, and is produced by many different teams. As a result it's now hosted on several different server architectures, with , our messageboard system (aka DNA), externally commissioned and hosted sites and our to name just a few, all using different .

To update content, like the masthead, on all these different stacks used to require making the change several times, on several systems. no longer however, because our page templating application, Barlesque, is now used by them all.

Last time I posted on the blogs about Barlesque I discussed a little of the early client side development work we did when designing it. Now I'd like to turn to the server side, specifically how we initially made it available to all the server stacks mentioned above, and also the challenges we've faced in the last 8 months migrating it to our new and shiny technical platform.

The core SSI system

When we got the go ahead to redevelop the previous page templating system, Barley, the first place we needed to make the new system available was our core environment at www.bbc.co.uk. In 2007-8, this meant Apache, mod-include (aka ) and not much else. This gave us includes, variables, conditionals (including regular expressions) but no loops, arrays, functions, databases and so on. On the plus side it's as fast as a greased eel, so can be used on every page of the site without making our sys admin folk cry.

As a result the way developers use this interface to Barlesque is pretty trivial. First set some configuration variables, for example:

<!--#set var="blq-footer-colour" value="black" -->

Then include the head, masthead and footer includes in amongst the normal html, for example:

<!--#include virtual="/includes/blq/head.sssi" -->

And the new page is ready and waiting for content.

But what if the site in question isn't on the www.bbc.co.uk architecture - like news stories, search results or one of the many externally-hosted sites the ³ÉÈËÂÛ̳ commissions every year?

The SSI webservice

Actually, it was quite simple to bridge this gap - we just made three .shtml pages that used SSI to include the three parts of Barlesque (head, mast and foot) and let all the external sites call them in over http.

Then, thanks to an open source ³ÉÈËÂÛ̳ Apache module called mod_setsplitvars the webservice can be configured via the query string:

www.bbc.co.uk/includes/blq/webservices/head.shtml?blq-foot-colour=black

This query string interface also means the webservice response is cachable (with some the headers set using to prove it), vital to ensure we didn't introduce cross dependency with the journalism stack in particular.

All good. Then the fun started.

The new ³ÉÈËÂÛ̳ Tech Platform

Over 2008 our new server architecture was rolled out. Known internally as 'Forge', it's a fully dynamic architecture, with PHP, the and its structure. This meant going and getting the webservice wasn't a problem for the early Forge-based sites like Lab UK, but it also meant it was a very appealing platform to be developing key products like Barlesque on. So 8 months ago we decided to move house.

The core Forge system

The first step was to rewrite Barlesque on Forge (the bottom circle on that crazy spaghetti chart), which straight away has meant the code getting clearer and less hacky, and abstracting all those separate pan-site projects like the survey and the advertising system that got tangled up with Barlesque simply because SSI knew no better. Win.

We also took the opportunity to make some much needed tweaks to our variable naming - losing SSI's slightly rubbish manual namespacing, and my slightly rubbish Americanisms:

var name="blq_footer_color"

Becomes:

$blq->footerColour;

This did however leave us with two code bases, SSI and Forge, which proper programmers tell me is a Bad Thing, so...

SSI stack interface on Forge

...We had to find ways of migrating use of Barlesque on the SSI stack to Forge.

Unfortunately we couldn't realistically ask the last two years worth of sites released on the SSI stack to go back and update their Barlesque calls. Instead we built another simple layer that compiles all the SSI variables into a query string, using lots of not-very-sexy SSI like this:

<!--#if expr="$blq_footer_color" -->
    <!--#set var="blq_qs"
        value="${blq_qs}&blq_footer_color=${blq_footer_color}" -->
<!--#endif -->

That query-strung request could then be proxied (again via a caching layer) to a new interface on Forge that mapped the SSI API values to the Forge ones. Once done, the existing SSI-based sites could be switched to Forge Barlesque without making any changes.

One neat trick here: We were able to collect the head, mast and foot content in a single call rather than three, by returning some html for the head, and two large SSI variables for the mast and the foot. A nice win.

The Forge webservice

Finaly we migrated the SSI webservice to point at Forge. Not hard, just a proxy pass from SSI to a third Forge interface, and some foreach($params as $key => $value){} taking the place of setsplitvars.

All done.

Um. Actually not quite. Just for fun there's a fourth interface:

Old Forge interface

Remember I mentioned those early Forge sites, like Lab UK, that used the SSI webservice to get Barlesque off the old SSI stack? Well Barlesque just moved to Forge, so it would be a bit mad to still be going to the old servers to collect it, then being proxy-passed straight back. So we've rewritten that interface too, using the same configuration mapping array as the webservice and SSI interface to use Forge Barlesque directly.

Thus after 8 months we're finally back down to one codebase, and so we only had to write the new masthead once, and the same goes for all the exciting new features we have coming in the future too - heads up!

Mat Hampson was Senior Client Side Developer, ³ÉÈËÂÛ̳ FM&T Intrernet Group.

Comments

Ìý

More from this blog...

³ÉÈËÂÛ̳ iD

³ÉÈËÂÛ̳ navigation

³ÉÈËÂÛ̳ © 2014 The ³ÉÈËÂÛ̳ is not responsible for the content of external sites. Read more.

This page is best viewed in an up-to-date web browser with style sheets (CSS) enabled. While you will be able to view the content of this page in your current browser, you will not be able to get the full visual experience. Please consider upgrading your browser software or enabling style sheets (CSS) if you are able to do so.