Alex Knowles

So we launched the new look moonfruit portal site today:

http://www.moonfruit.com/

It got some coverage in techcrunch.

It uses the rather awesome Dancer.

I mentioned it on the Dancer-users list, who seemed to like it, and wanted to know more. Below is reproduced from a post to the dancer-users.

The main Moonfruit service allows users to create sites in flash in a handy draggy droppy way (it being flash).

To do this we have a sprawling, slightly legacy, (but getting much better) Plack based set of API's.

The plan was to upgrade the portal from this (which was basically completely static html).

To a shiny web 2.<whatever we're on now> dynamic system.

So we have 3 collections of routes (ish):

MF-Portal/lib/MF/Portal.pm
MF-Portal/lib/MF/Portal/API.pm
MF-Portal/lib/MF/Portal/Support.pm

1: Serving the HTML

My filthy Assistants (*) put the html into TT (which they'd learnt on a previous project (which was rendering the flash objects into html for desktop and mobile devices)).

The html pages aren't that dynamic, as it's all done by writing to the DOM with ajax (strictly speaking i guess it's ajaj since we use json) but probably a: will be and b: should be :)

This is pretty standard Dancer / TT stuff, take route, drop a template with some stuff. We have some quite nice bits to set things like the footer nav on start up from a conf file, which is also used to serve sitemap.xml (in an idea stolen from Dancer::Plugin::Sitemap) :), but basically this part is all straight route->template type thing.

One nice thing about using dancer was that once I'd built a very basic platform for the html pages the front end guys were building TT and filling out mock data in the app so they could develop the front end on their own.

<insert gag about dancer being so simple a front end engineer can use it here> :)

2: API calls to the backend

This is the meat of the app, as mentioned above, we could flatten most of the html and serve it statically at the moment.

The dynamic bits: logging in, fetching site information, billing info etc etc are all done with a REST (ish) interface in a separate package, using the very sexy and fabulous Dancer::Plugin::REST

This then uses MF-Portal/lib/MF/Portal/Plugin/JSONRPC.pm

This registers a method api_call which does authenticated JSON RPC to our main api, by doing things like:

get '/some-resty-url/all.:format' => sub {
my $url="/$somebackend-api-call/";
my $method="doSomething";
my $params=["all"];
my ( $data, $error ) = api_call( $url, $method, $params );
return status_bad_gateway("api not available") if $error;
# do some stuff with the data, maybe make a secondary api call
# knit it all together
return $data;
};

I'm using JSON::RPC::Client to do this.

3: Support calls

We're using zendesk to do handle our front line support for the product (which is new with this release), and we're using their Remote auth, so there's a pile of interesting and smart stuff involved in that.

If you click on a link with /zendesk/ (which should really be /support/*) you get redirected via their remote login system if you're logged into our portal, which then logs you into there.

That's basically it. There's a few interesting bits and bobs, and I hope to be able to release some stuff back out to CPAN - I'm pleased with the JSON::RPC plugin, and the zendesk integration (in fact a general zendesk api perl module would be useful).

Oh and there's a pretty much throwaway plugin:

MF-Portal/lib/MF/Portal/Plugin/ConfigBackup.pm

which is for lazy loading - on startup the slow moving data is fetched then stored in a tmp file in case something goes away.

Oh and session handling is done with Dancer::Plugin::Memcached although i'm looking at subclassing that to do selective sessions (i.e. only drop a cookie on session->flush) - it's written just not tested yet.