Login if you already have an account



Create a new account. join us!



Need some help? Check out our forum.


PaaS? BaaS? What?

Lots of people ask about the origins of NoServer, which is what we call FatFractal’s BaaS module.

We were in the process of building out our cloud fabric and one night, while building yet another demo app, I decided that all developer-centric cloud platforms really also ought to offer a way for developers to get 90% of what they need for the server-side of their app, out-of-the-box, while also trying to ensure that we not fence them in – i.e. give lots of functionality with minimum effort whilst also giving flexibility and extensibility to go beyond the box as you reach the edges of what is initially provided.

The 90% boiled down to the following. The cloud should:

  • Store and retrieve my objects.
  • Securely – permissions and security should be robust and at a fundamental level.
  • Efficiently – with easy to create queries that get me what I want.
  • Execute code on the backend when my data changes (events).
  • Not prevent me from doing anything else that I want to do.

The last point is really important! Whilst getting the other things makes my life a lot easier and will make me very happy for a month or two, if the flip side is that I then get stuck and as a result get frustrated and miserable, then I wouldn’t want it. So by June 2012 we had built enough to trial with customers – who loved it! – we launched our public beta in September, worked through the kinks in Oct-Dec :-) and we are now really focussed on getting the word out.

Meanwhile, some new marketing terms were emerging from other similar, but essentially different approaches. Platform as a Service (PaaS) and Backend as a Service (BaaS) are now terms that are used widely.

Upon reflection, it seems to me that they are both missing the point. PaaS is still very focused on a historical view of a set of IT problems, i.e. “stacks”. BaaS is seeking to provide more of a turnkey solution for application developers that treats the backend as a black box and is extremely limiting, invasive and prescriptive (smells like attempts at lock-in to me).

IMHO – what the market needs is a bit of both: a very smart cloud fabric that deals with infrastructure, monitoring, scalability, reliability, resilience etc, and also provides the ease of creation and out-of-the-box features that BaaS does, but does not limit the developer as a result. If I want to deploy some Java Code, Ruby Code or anything else in order to do something that I want to do, right alongside my “BaaS” stuff, then I should be able to.

So – in a nutshell, what we have so far built into NoServer is:

  • True fully qualified REST URIs
  • CRUD persistence
  • SDKs that operate at the data level and do not encroach into your code unnecessarily.
  • Amazingly straightforward modelling of your object graph’s relationships
  • Natural language, chained queries nested as deep as you want.
  • Strong authentication. SSL of course. Declarative access controls for your data which is sufficient for almost all use cases while also providing programmatic control (directly setting ACLs on objects) for when the declarative approach isn’t enough (which, so far, has been incredibly rare)
  • Exposed CRUD events with defined Event Handlers that execute your custom JavaScript code when they occur with synchronous (PRE or POST) as well as asynchronous modes. Currently we use RingoJS which allows you to do pretty much anything you need to do, including make HTTP requests; we also supply an API for sending Apple/Android push notifications, sending emails, image processing, and of course full access to your app’s datastore.
  • Server Extensions that allow you to extend your API with whatever server-side processing you want, and the ability to schedule scripts to run whenever you like

We’re pretty flexible at the server-side already, and I think you’ll agree we’re already better than (or *at least* as good as!) our BaaS competitors, but there’s lots more to come. Here’s a list of some of what’s coming over the next six months or so!

  • Greatly enhanced and pluggable authentication framework so that you can script integration with pretty much whatever 3rd-party identity / authentication cloud you like
  • Event Handlers for GET requests, and ‘virtual’ collections
  • Allowing mix and match of the powerful declarative access controls we already have with your own javascript for the really really edge cases (like, only allow access to this object if the current user lives in Idaho)
  • Enabling integration between NoServer and Rails backends. This is a big step towards completing our vision – i.e. if you reach the limits of what NoServer provides, then you should be able to extend your backend with some Ruby-on-Rails, or Java servlets, or NodeJS, or whatever
  • Allowing use of NodeJS modules in your NoServer server-side scripting

  • Full support for NodeJS applications on the FatFractal PaaS, and integration between NoServer / Node / Rails / Servlets modules in your app’s backend
  • And last, but definitely not least – and probably the most personally exciting to me given where I have spent a lot of my working life (i.e. large enterprise IT) – we will be working on evolving our products so that they can be leveraged by enterprises. More on that when the time comes :-)

I hope that you like what we have built – would very much appreciate your feedback.



In case you’re curious – NoServer is a tribute to the no-stuff (chamber, room, globe, ship) in Frank Herbert’s most excellent Dune series.

Now supporting Ruby and Servlets

We are proud to announce support for the deployment of Ruby applications... with support for both local development and deployment to the FatFractal cloud.

We are proud to announce support for the deployment of Ruby applications (e.g. Rails, Merb, Sinatra), leveraging the JRuby and Rack frameworks with support for both local development and deployment to the FatFractal cloud.

The Ruby programming language is very popular, especially when it comes to the cloud, thanks to the excellent work of folks like Heroku and Engine Yard. JRuby has been gaining significant momentum as a framework for developing and deploying Ruby applications and is the basis for our Ruby cloud environment. Developers have been asking that our platform support Ruby and so we have made that support a priority.

Unlike other Platform as a Service (PaaS) offerings, FatFractal facilitates all framework and language support through its module architecture which provides for the dynamic provisioning of the necessary functionality based on an application’s requirements: if an app requires Backend as a Service (BaaS), we provision the NoServer module and if an app requires Ruby, we provision the Ruby module. This dynamic provisioning lets the FatFractal Engine optimize its execution footprint and support multiple frameworks and languages within the context of a single engine.

What are we releasing?

This announcement is the first of several to come as we continue to integrate additional backend frameworks and languages into the FatFractal module architecture. The module architecture is the blueprint by which FatFractal provides polyglot capabilities to its BaaS and PaaS offerings.

FatFractal’s Ruby support is based on JRuby/ Rack running in our new Servlet module (which is also included with this release). This means that traditional Servlet applications, such as Servlet/JSP and Spring applications are supported as well.

Our vision for the future of the FatFractal Platform is a full polyglot environment that allows a single application to leverage more than one module at the same time while sharing backend services available on the platform through SDKs. For example, it is not uncommon for Ruby on Rails applications to tap into a Node.js deployment for notifications. Since our NoServer module supports native push notification services, Ruby developers will be able to use cross module support to leverage that service, even though it utilizes a different module.

Today’s release includes the expected support for a Ruby on Rails application. Going forward FatFractal will provide Gem support, allowing Ruby developers to access FatFractal cloud services such as payment, search, datastore, and  etc.

The FatFractal Ruby environment supports the following technology components :

  • jRuby 1.7 (Ruby1.9.2)
  • Rack 1.4
  • Rails 3.1
  • Servlets 2.5
  • Mysql 5.1
  • Warbler 1.3.6

How can I start using Ruby on FatFractal?

The Ruby release is expected to be available on November 23rd. You can then download the latest release of the FatFractal engine and Command Line libraries by visiting Getting Started to begin using Ruby on FatFractal.

We invite you to check out our Ruby and Servlet support and provide feedback prior to our general availability release. The documentation for configuring and deploying your Ruby application should be posted by November 23, 2012 and we’ll put the link here at that time.

We are always delighted to hear from you, whatever you have to say.

Have fun – happy coding!

Kevin Nickels (uber hack)