Cloud Connected

Building Applications with Ratchet JS MVC

Over the past few days, I’ve had a chance to delve back into ratchet.js which is a JavaScript MVC framework that I had a hand in building in 2010. By this point, there are a lot of JavaScript MVC frameworks that you can utilize. However, at the time we built it, we were very inspired by sammy.js, backbone.js and knockout.js.

A few points on these libraries:

  • I particularly liked sammy.js for its simplicity. The developers of that library do a great job minimizing the work and also utilized an interesting “chaining” approach during the rendering phase which was inspirational. We really liked the chaining approach and used it in Ratchet as well as our own Cloud CMS JavaScript Driver.
  • Both backbone.js and knockout.js are fantastic frameworks for defining scoped-observable variables in the model. They solve things like how to update content on the page in real-time, build components that listen for update events and pass messages between controls or elements on the site.

We sought to produce an MVC library that gave us the singular foundation that we needed to build really great HTML5 and JavaScript-based applications. Furthermore, we wanted a framework that would be ideal for real-time, cloud-connected applications. Thus, while it’s important to get the foundation bits right in terms of observables, components, templates, routes and so forth, we also felt it was very important to define an asynchronous rendering pipeline that could manage state for the backend, stream content forward and aggregate it into HTML5.

None of that is really too outlandish. A few years ago, for those old enough to recall (not that it was that long ago), everyone was crazy about mashups. The basic idea behind mashups was that content would be sourced from other locations and presented singularly. That idea hasn’t gone away and with the explosion of cloud-based services including Cloud CMS for all of your content and application services, we think its high time that a JS framework was built to address that need.

So that’s where we’re headed going forward. I find it an absolute joy to work with ratchet.js and would recommend to readers that they take a look. It’s a purely open-source project under the Apache 2 license. All of the source code is available on GitHub.

Grand Opening

Today our young company achieved its first major milestone. Today we officially launched our Cloud CMS platform. Today is our grand opening.

On this important day, I want to share with you a conversation that happened a few days ago between me and my mom.

“Son, tell me something about the project that you are working on. Explain to me why you think it will be a success.”, my mom asked.

While I consider my mom to be the most intelligent woman in the world, she has very little knowledge in computer or software.

It was a challenge for me to explain it in such a way that my mom could understand.

“Ma, just think we are builders and running a property management business. Our customers rent space from us while we will take care of their need for wifi, electricity, water, gas, AC etc. We are also their security guards and janitors. We even mow the yard and plow the snow for them.”

“When rent a room, all the plugs are there and they can start to build their own business just the way they want. They might be a department store, a restaurant, a barber shop or even something as small as a lemonade stand.”

“They will only pay for the utilities and the space they rent. If they need more space or plugs, they can have them right the way. When they don’t need them, they won’t need to pay for them.”

“Since we are experts in constructing buildings, producing high-quality and friendly plugs, and all maintenance work, we can make things very cost effective for our customers and still make a healthy profit. Our customers can then focus on the things that they are good at and leave the utility stuff to us.”
“Another really cool thing is that our customers can also sub-lease their space to their own customers. And their customers can enjoy the exact same service as they have. They can bill their own customers any way they wish while we will only charge them based on the reading of their utility meter.”

“This is something that nobody else can provide today.”

My mom seemed to get what I said. She nodded her head and said

“Son, I know you are doing the right thing and I wish for it to be a big success!”

I believe that is what we have produced. It is a unique platform that brings fresh air to the CMS and Cloud space.

I hope you will share our vision and passion and give our Cloud CMS a try.

Dynamic ProxyPassReverseCookieDomain with Apache 2

We do a lot of HTML5 and JavaScript application hosting at Cloud CMS.  Our platform lets you build HTML5 applications and deploy them to our cloud infrastructure with just a couple of clicks.  As a result, we’ve gotten pretty friendly with Apache 2, virtual hosts, mod_rewrite, proxies and more.

Applications built on our platform use OAuth2 over SSL.  We support all of the authentication flows even for HTML5/JS applications.  Inherently, these applications are considered “untrusted” in any two-legged flow (such as username/password).  And with good reason - it’s simply impossible to store private information within the browser.

Heck, even your aunt Mildred could “view source” and poke around to find passwords, ids or other important “private” things sitting in your source code.  Plus, anything you put into source could be cached.  Searched.  And made public.  How ‘bout them apples?

With Cloud CMS powered apps, we recommend using a three-legged OAuth2 flow for all HTML5 and JS applications.  With a three-legged flow, the application never “sees” your private credentials at all.  There’s a bit more hopping around but, for the most part, it’s totally seamless for the end user.

Might resemble your aunt Mildred

Cloud CMS goes a step further and gives you some security enhancements that you can use for two-legged scenarios.  For one, we let you dynamically configure your domains so that you can lock down exactly which hosts are allowed to authorize.  You can also do things like create secondary client and user key/password credentials.  If a pair goes awry, you can shut them down and issue new ones.  Wallah!

A lot of these security enhancements are built around the ability for users to deploy Cloud CMS backed applications to new domains quickly.  Setting up web servers is an art and often takes a good deal of man power.  Thus, we’ve built out a fully dynamic solution that uses Apache 2, mod_rewrite and proxies.

As you might guess, we use a wildcard SSL and virtual host configuration.  One of the things we need to do is hand off requests from the HTML5 app through a proxy back to our content management API.  Our API handles the request and responds.  On the way back out, all cookies need to be mapped into the domain of the browser.

It turns out this isn’t the most intuitive thing with Apache 2 to do.  The ProxyPassReverseCookieDomain directive is good but it doesn’t support dynamic variables straight away.  In our case, we have a wild card virtual host and we’d like to be able to tell certain Set-Cookie headers to swap their domains for our selected wildcard match.  How does one do this?

mod_rewrite: first to Alpha Centauri

Our solution was to use mod_rewrite to set an Apache environment variable.  Interesting, eh?  Not exactly what mod_rewrite was intended for (perhaps).  But frankly, mod_rewrite seems like one of those plugins that can do just about anything in the universe.  I am sure when they get to Alpha Centauri, they will discover that mod_rewrite was there first.

I digress.  So we use mod_rewrite to copy the ${HTTP_HOST} variable into an environment variable.  And then we use the proxy pass interpolate feature to plug the environment variable into the cookie.

It looks like this:

 <VirtualHost *:80> 
 ServerName *
 DocumentRoot "/apps"


 # Use Mod-Rewrite to copy %{HTTP_HOST} into 
 # an Apache environment variable called "host"
 RewriteEngine On
 RewriteRule .* - [E=host:%{HTTP_HOST}]

 # Stop! Proxy Time!
 ProxyRequests Off
 ProxyPassInterpolateEnv On
 ProxyPass /proxy http://localhost:8080 interpolate
 ProxyPassReverse /proxy http://localhost:8080 interpolate
 ProxyPassReverseCookieDomain localhost ${host} interpolate



Hopefully this proves useful for others.  If you’re interested in learning more about Cloud CMS, just hop on over to our site at and sign up for an account.  

We’ll post more cool tips as we find them!