Incapture Technologies

Inside the Cloud

Incapture Technologies Blog

 

Building web applications on Rapture

Published:
February 26, 2015
Author:

In this next set of Rapture blogs I want to explore how we at Incapture build web applications on Rapture. You can use this same technique to build your own applications on Rapture as this framework is part of the general Rapture product. This is not the only way to do this – Rapture is a platform after all and there are many ways to use such a platform to create such an application.

As a taster for what I’ll be talking about I can show you a demonstration “front page” of our sandbox application:

Screen Shot 2015-02-26 at 1.49.22 PM

Here we have a tileset of “applications” that we have installed into this environment, and the ability to launch them. Over the next couple of blog posts I’ll explain behind the scenes how I used the framework to create these applications.

We should first consider what our requirements and constraints are for such an application framework. Ideally I wanted to have a very simple deployment approach – it should be straightforward to “add” an application to an existing environment – and to be able to do that in a more containerized deployment as well. I also didn’t want to have to compile and deploy “binaries” each time I changed a small aspect of an application. Finally it would be nice if I could examine and make minor modifications to an application from within Rapture itself.

In this introductory post I’ll simply talk about the underlying features of Rapture that will be used in this application framework. Subsequent posts will take each part and show how it all comes together.

The most fundamental parts of a web application is its static content – the html pages, the images, the javascript code and stylesheets. Within Rapture we have a good place to put such content – we call it a “blob repository”. Content in a blob repository has a mime type (which is very useful when serving content) and can also be versioned (which is very good if we make a mistake and we need to roll back content). We will need to have a way to serve content to anonymous users who haven’t logged in yet and to serve application content to those who have. Rapture’s security and entitlements model will help here.

The other aspect of a web application relates to the dynamic content. An earlier blog post talked about this but one way this can be achieved in Rapture is by serving the dynamic content (usually called via ajax calls from a javascript context on the client) through the deployment of Reflex scripts. Using scripts in this way helps to mitigate large amounts of data being passed for local processing.

Finally we’ll need a way of packaging up this content into something that can be easily deployed to an application instance. Rapture has a concept called “Features” which is an ideal match for this type of deployment approach. Even better – features can be packaged into a self-installable executable which we can run against an environment in a repeatable way.

So with static content, scripts and then the “real” data and workflows associated with our application we can very quickly create applications that can run in a Rapture environment. The end point for this blog journey will be to explain how we can create an application that can present this type of information:

Screen Shot 2015-02-26 at 2.03.06 PM

Watch this space (or subscribe using the button up and to the right) for more updates on this exciting way to build applications on Rapture.


Subscribe for updates