X
X

Login

Login if you already have an account

LOGIN

Register

Create a new account. join us!

REGISTER

Support

Need some help? Check out our forum.

FORUM
Welcome to our Blog

The Post

We’re working on new stuff!

We’re constantly trying to push the boundaries of what the FatFractal platform can do! Here’s a little preview of whats to come:

Features Roadmap

WebsocketsReal-time, persistent connections and live queries provide more interactive applications and support for games applications.
Nashorn Integration
Provides support for running Node.js modules as custom code.
Client-Side Query Support
Query cached data directly with support for the FatFractal Query Language on the client SDKs.
Graph Edge Attributes
Ability to add attributes to relationship definitions.

Got any suggestions for features you’d like see? Let us know right here.

NoServer Features

We have eliminated the tedium so your development efforts can be directed towards creating amazing user experiences and engaging apps.

NoServer is the world’s first meta-data driven system that creates beautiful APIs for your applications instantly. Based on our patented “Datagraph” technology, external data can be seamlessly integrated together with application data into a single well-formed REST API for your application.

Open, efficient client SDKs and our nested query language make it easy to build mobile and web apps using your APIs that are smaller in size, perform better with lots of advanced features like caching and offline queuing that available out of the box.

Sign Up to use all these amazing features.

Feature
Benefit
Metadata driven API
Define your API much faster with the FatFractal Definition Language (FFDL).
Objects and Collections
Full control of your API structure with defined Objects as well as Collection resources.
Fully qualified URLs
Your API is identified as a fully qualified URL compared to others that use their URL plus API keys to define an API location.
API metadata
All APIs have a metadata description that you can elect to expose to make it easy to integrate with other APIs/ Applications.
Object metadata
All objects offer system generated metadata (createdAt, createdBy, collection, URL, editable, GUID, version, updatedAt, updatedBy) that is accessible by the client SDK.
User management
Powerful, secure user management is provided out of the box (note - user authentication via external sources using any OAuth 1.0a and 2.0 compatible API.
Permissions
Permissions can be controlled at the API, Collection and Object level, including cascading permissions.
DatagraphExpressive, navigable object relationships (References, GrabBags and Back References) provide unprecedented flexibility for creating rich data representations.
FatFractal Query Language
A nested query language allows you to “walk” your datagraph (filters, traversals, sorting, limiting, response depth) in order to get to the full graph response that you want in a single query.
API Level Security
API level security (private collections, anonymous access, system user options, allowed and disallowed GET patterns) provide control over how your API can be accessed.
API Metadata Access
You can control whether the API metadata is accessible or not.
Declarative Collection Permissions
You can define the default read and write permissions for any Collection using Declarative Permissions
Encryption at Rest
You can define Object member level data to be stored Encrypted at Rest.
Authentication
There are a number of FFDL settings that give you additional control over how users authenticate to your API, including registration behavior, password validation and required formats and responses and session timeout settings.
Business Logic (Event Handlers)
Event handlers execute when a data event occurs on your API and are one of the most powerful and unique aspects of the FatFractal Platform. Every CRUD action automatically generates an event that may trigger an event handler, without your defining or coding up those events.
Data Integration (Virtual Collections)
Developers can combine data from external sources into the FatFractal Datagraph making all of the great features of navigating the graph available seamlessly using Virtual Collections that can communicate directly (JDBC) or via REST integration using the provided HTTP Client on the Serverside SDK.
Custom Endpoints (Server Extensions)
Server Extensions execute serverside functions that you create to define custom endpoints for your API.
Automated Functions (Scheduled Code)
FatFractal’s NoServer supports scheduled execution of scripts on the backend.
Push Notifications
The NoServer framework makes easy to use both Apple and Android push notifications in your applications.
Email Notifications
The NoServer framework makes easy to send email notifications from your applications.
Client SDKs
FatFractal provides iOS, Android, BlackBerry, HTML5/JS SDKs that are smaller, more efficient without external dependencies and are less proprietary than all the others.
Deployment Options
The FatFractal Platform can be deployed and run anywhere you wish onto Cloud Infrastructures, or basic virtualized datacenters.
Local Development
You can also run the FatFractal Platform on your development machine greatly speeding up application development and debugging.
Relational Support
Should you need more traditional database support, any collection can be defined as a relation collection exposing relational query support.

FYI – FatFractal Makes File Upload Easy

You can access the source code for the sample application here.

Inspired by a recent blog post by Raymond Camden, we decided to show how much easier FatFractal makes it to create an object containing a blob. This example uses our JavaScript SDK in a PhoneGap app, but all of our SDKs feature the same ease of use.

Here’s the relevant code for uploading with FatFractal:

// Not even a little bit complex -- just set the member
var newNote = {
clazz: "Note",
text: noteText
};
if (imagedata) newNote.picture = imagedata;
ff.createObjAtUri(newNote, "/Note", function(result) {
$.mobile.changePage("#home");
}, function(error) {
console.log("Oh crap", error);
});
cleanUp();
Here’s the Parse code (from Raymond Camden’s blog):
/*
A bit complex - we have to handle an optional pic save
*/
if (imagedata != "") {
var parseFile = new Parse.File("mypic.jpg", {base64:imagedata});
console.log(parseFile);
parseFile.save().then(function() {
var note = new NoteOb();
note.set("text",noteText);
note.set("picture",parseFile);
note.save(null, {
success:function(ob) {
$.mobile.changePage("#home");
}, error:function(e) {
console.log("Oh crap", e);
}
});
cleanUp();
}, function(error) {
console.log("Error");
console.log(error);
});
} else {
var note = new NoteOb();
note.set("text",noteText);
note.save(null, {
success:function(ob) {
$.mobile.changePage("#home");
}, error:function(e) {
console.log("Oh crap", e);
}
});
cleanUp();
}
(The only other significant change was to switch to reading the image from the filesystem rather than receive it as a base64-encoded string, which is arguably better practice anyway. Check out the full source up on GitHub!)

So, instead of forcing you to create and save a special file object, FatFractal lets you do the natural thing: you set the member, we take care of the rest.

Many-to-Many Relationships & NoSQL? Problem solved.

I’m an engineer and not usually given to making sweeping statements like, “we’ve solved the many-to-many relationships problem for NoSQL;” but in this case, I hope you’ll agree, it’s merited.

In short, with FatFractal we have created a simple and efficient way for you to code extremely-complex relationships between models.

The many-to-many relationships problem is classic and one which SQL solved long ago with joins. However, there are a couple of well-known issues: 1) a very large number of join tables can become so complicated that you’re better off re-architecting your data model; and 2) in the cloud, even with a good sharding strategy, you can run into scaling problems when things go big.

Developers do one of two things in NoSQL to relate objects to each other: either add a field for each object containing referents to the other or add a third object containing the relationship between the two (can you say “join table?”). These options are talked about in lots of places, see for example Google’s take and Kinvey’s and Parse’s. In each of these main approaches, the clientside, code complexity increases for every new relationship; if you add lots of different relationships, across lots of objects, your complexity grows geometrically to failure.

FatFractal’s solution is a backend datatype called ‘GRABBAG’. Simply put, a grab bag is a set of references to any number of other objects – potentially, any collection and potentially, any objecttype. Grab bags are not part of your object model: they are maintained separately by your app’s backend and we give you methods to CRUD them from clients.

Enough talk – let’s do code.

To show you how straightforward we’ve made these many-to-many relationships, we’ll create a ‘Movie’ object and a ‘Theater’ object. A movie can be showing in many theaters and a theater can be showing many movies. First, we need a method to allow movies to be added to theaters.

We’ll model up the data using our simple, markup language, FatFractal Definition Language (FFDL, “fiddle”) saved to a config file (there are other options for modeling—but FFDL is particularly easy to follow):

CREATE OBJECTTYPE Theater (theaterName STRING, location GEOLOCATION, movies GRABBAG)
CREATE OBJECTTYPE Movie (movieName STRING)
CREATE COLLECTION /Theaters OBJECTTYPE Theater
CREATE COLLECTION /Movies OBJECTTYPE Movie

Here’s a set of Objective-C interfaces:

@interface Movie : NSObject
@property (strong, nonatomic) NSString *movieName;
- (void) getTheaters:(id )delegate;
@end

@interface Theater : NSObject
@property (strong, nonatomic) NSString *theaterName;
@property (strong, nonatomic) FFGeoLocation *location;
- (void) getMovies:(id )delegate;
- (NSError *) addMovie:(Movie *)movie;
@end

@protocol SimpleLoadProtocol
- (void) didLoad:(id)data;
- (void) didFailLoadWithError:(NSError *)err;
@end

Here’s the Objective-C code required to implement Theater’s addMovie and getMovies methods:

- (NSError *) addMovie:(Movie *)movie
{
NSError *err;
[[FatFractal main] grabBagAdd:movie to:self grabBagName:@"movies" error:&err];
return err;
}

- (void) getMovies:(id )delegate
{
FatFractal *ff = [FatFractal main];
__block id theDelegate = delegate;
[ff grabBagGetAllForObj:self grabBagName:@"movies" onComplete:^(NSError *err, id movieList, NSHTTPURLResponse *theResponse) {
if (err)
[theDelegate didFailLoadWithError:err];
else
[theDelegate didLoad:movieList];
}];
}

Yes, that really is it—just add a ‘movies’ member of backend datatype GRABBAG to the Theater OBJECTTYPE and everything else is taken care of for you. Happily, even though the grab bag is defined in your Theater OBJECTTYPE, as far as your app and its backend are concerned, both the model and the data are held separate-and-apart from the Theater objects.

Relationships can come and go, while your clientside and serverside object models stay pure.

Some Test Data (showing relationships)
Theaters
Movies
BalboaThe Artist, Balboa
CastroMelancholia, Tree of Life, The Trip, A Separation
LumiereBeginners, A Separation, Melancholia
Some Snippets:

Add a movie “The Future” to show at Theater Balboa:

Movie * theFuture = [[Movie alloc] init]; // create new movie
[theFuture setMovieName:@"The Future"]; // its name is “The Future”
[ff createObj:theFuture atUri:@"/Movies"]; // save it!
Theater * balboa = [ff getObjFromUri:@"/Theaters/(theaterName eq 'Balboa')"];
[balboa addMovie:theFuture]; // add the movie

All that the addMovie method is doing under the hood is:

[[FatFractal main] grabBagAdd:theFuture to:balboa grabBagName:@"movies" error:&err];

Query: Show all movies at the Lumiere theater:

NSArray * moviesShowingAtLumiere = [ff getArrayFromUri:@"/Theaters/(theaterName eq 'Lumiere')/movies"];

What about getting the list of theaters that a movie is showing in?

For every “forward” relationship represented in a FatFractal object, whether by a REFERENCE or a GRABBAG, FatFractal automatically creates and maintains the “inverse relationship” from the referred-to object. Those inverse relationships are available through the system-maintained ‘Back References’ GRABBAG. Every object’s back references are kept by the system grab bag. And why not? After all, grab bags are not part of your clientside data model or your serverside data model; so there’s no impact on you or your code. Create as many grab bags (i.e. relationships between objects) as you like. Your code will stay elegant and simple.

Without any more modeling required, here’s a method to get the Theater objects where a movie(s) is playing:

- (void) getTheaters:(id)delegate
{
FatFractal *ff = [FatFractal main];
__block id theDelegate = delegate;
[ff grabBagGetAllForObj:self grabBagName:@"BackReferences.Theaters.movies" onComplete:^(NSError *err, id theaterList, NSHTTPURLResponse *theResponse) {
if (err)
[theDelegate didFailLoadWithError:err];
else
[theDelegate didLoad:theaterList];
}];
}

Query: Show me all the theaters where “A Separation” is playing.

NSArray * theatersShowingASeparation = [ff getArrayFromUri:@"/Movies/(movieName eq 'A Separation')/BackReferences.Theaters.movies"];

The syntax may seem a bit strange but it means,”start with the /Movies collection and select those Movie objects with movieName equal to “A Separation.” From that set, give me the list of objects in the /Theaters collection whose ‘movies’ member references the previous list of objects (in this case, a single Movie object, ‘A Separation’). In plain English, give me all the Theater objects pointing to the Movie object ‘A Separation.’

Here’s the real payoff: let’s say we want to add relationships between Movie objects and movie stars. Obviously, movies have multiple stars and stars can be in multiple movies. Let’s add a movie star model and set up yet-another, many-to-many relationship:

CREATE OBJECTTYPE Theater (theaterName STRING, location GEOLOCATION, movies GRABBAG /Movies)
CREATE OBJECTTYPE Movie (movieName STRING, stars GRABBAG /Stars)
CREATE OBJECTTYPE Star (movieStarName STRING)

CREATE COLLECTION /Stars OBJECTTYPE Star
CREATE COLLECTION /Theaters OBJECTTYPE Theater
CREATE COLLECTION /Movies OBJECTTYPE Movie

Data set: showing relationships
Theaters
Movies (Stars)
BalboaThe Artist (Jean Dujardin, Bérénice Bejo), Babel (Brad Pitt, Cate Blanchett, Gael García Bernal)
CastroMelancholia (Kirsten Dunst, Charlotte Gainsbourg), Tree of Life (Brad Pitt, Sean Penn, Jessica Chastain), The Trip (Steve Coogan, Rob Brydon), A Separation (Peyman Moadi, Leila Hatami)
LumiereBeginners (Ewan McGregor, Christopher Plummer), A Separation (Peyman Moadi, Leila Hatami), Melancholia (Kirsten Dunst, Charlotte Gainsbourg)

Simply adding ‘stars GRABBAG /Stars’ to the Movie objecttype establishes the new relationship. No additional tables or code complexity or future code maintenance headaches. And you can do some pretty cool queries!

Query: Get all the stars in all of the movies showing at the Lumiere.

NSArray * starringInMoviesShowingAtLumiere = [ff getArrayFromUri:@"/Theaters/(theaterName eq 'Lumiere')/movies/()/stars"];

Query: Show me all the movies that Brad Pitt stars in.

NSArray * bradPittMovies = [ff getArrayFromUri:@"/Stars/(movieStarName eq 'Brad Pitt')/()/BackReferences.Movies.stars"];

Query: Show me all the theaters that are showing movies that Brad Pitt stars in.

NSArray * theatersShowingBradPittMovies = [ff getArrayFromUri:@"/Stars/(movieStarName eq 'Brad Pitt')/BackReferences.Movies.stars/()/BackReferences.Theaters.movies"];

(note: that back references syntax can get unwieldy so we have a way to “alias” those references.)

Now, just for fun (I stuck in a GEOLOCATION member in the object model just for this!), let’s find out which theaters are showing “Avengers Assemble” within 50 kilometers of the town of Nairn in Northern Scotland where I live:

[ff getArrayFromUri:@"/Movies/(movieName eq 'Avengers Assemble')/theaters/(distance (location, [57.5833, 3.8667]) lte 50000)"];

No more geometrically-expanding “joins” with all maintenance nightmares that such complexity entails. FatFractal offers a much simpler solution…and 50% is handed to you for free with back references! Model the relationships from theaters to movies and from movies to stars and the system’s back references let you traverse the datagraph in reverse: from stars to movies to theaters.

Create relationships. Save time. Stay sane…and have fun!

Nominate FatFractal’s API for the Data Week + API World Awards

dataweek api world FatFractal

As part of the DataWeek Event + API Conference, an awards show is to be held that will honor the most innovative API technologies across a wide selection of verticals and industries.

FatFractal has been nominated in the API Middleware category as one of this year’s most innovative API’s.

FatFractal has solved some of the fundamental issues for creating and interacting with expressive data that would otherwise pose a geometric explosion of complexity and all the associated performance, and access challenges that have terrorized developers until now.

Our patented Datagraph and Nested Query Language provides unprecedented capabilities for developers of modern applications that require secure, scalable, performant APIs with complex data representations that any developer can create and use instantly.

To nominate FatFractal here are some quick steps to do so before July 15th:

1. Sign up for an account here.
2. After you registered, click here and then on the black “Endorse” tab on the top.
3. Every endorsement makes a difference, and we appreciate your support!

The FatFractal Team

Enterprise In The Cloud

The Enterprise and Cloud

Today more than ever, large enterprises are adopting information technology services in the cloud. It provides operational and financial efficiencies that are simply too compelling to ignore, and allows IT departments to focus on their core competency.

So the questions is “Why has it taken large enterprises so long to adopt cloud environments?” The first thing usually comes to mind is Security. Nowadays, technology when implemented correctly provides the right security measures (i.e. SSL, VPN) to establish connections that are on the same level of security as any behind-the-firewall environment.

Wait out the storm

Conservative CIOs are simply waiting out the storm to allow others to make mistakes before they do. Integration plays a big role as well when it comes to linking cloud applications to other apps both in front of and behind the enterprise firewall. What seems to be the issue then?

Simply, CIOs are terrified of the idea that a cloud computing company holds their company’s entire data off-site, where the unimaginable could happen… it could simply vanish tomorrow. Service interruptions, data mismanagement, and bankruptcy are some of the common issues that usually come to mind.

Some Numbers

It was found that 65% of enterprise clients surveyed are using, or are planning to deploy using the private cloud model. Despite efforts of cloud computing vendors, and increased adoption in recent years, Security is mentioned as being very inhibiting by 70% of respondents, with Privacy at 69%, Uptime at 62% and Data Control at 61%. These seem to remain the most likely inhibitors to adopting cloud computing services and applications.

Enter FatFractal:

Feature
Benefit
More choices
Our solutions include public cloud, enterprise on premises, OEM integration, white label and private label.
Futureproofed
Deploy wherever you want - from our public cloud to your public or private cloud. Switch any time you want to.
Create cooler applications faster

Our Client SDKs provide lightweight, non-proprietary easy methods that accelerate the creation of mobile and web apps using your APIs so your development efforts can focus on creating great user experiences.

Speaks your language

Our Polyglot PaaS capability supports multiple programming languages to support both new and legacy applications.

Public cloud

The easiest way to get your ideas to market in record time for a lot less money.

Private cloud

Take full control of your environment whenever you want. Run it wherever you want.

Pick the bits you want

With a wide range of technology distributions, you are free to choose the features that you want to complement your offerings and deploy them wherever you want from public cloud, private cloud or on traditional virtualized environments.

With a wide range of technology distributions, you are free to choose the features that you want to complement your offerings and deploy them wherever you want from public cloud, private cloud or on traditional virtualized environments.

Leverage corporate data

Seamlessly integrate corporate data and application data with our Datagraph and Virtual Collections.

Integration support

We help accelerate time to market by providing support for integration with your offerings as well as providing training for your technical, marketing and sales staff.

Get the most out of your mobility infrastructure

The solutions that you create with FatFractal all play nice with your investments in mobility infrastructure like MDM, API gateways and analytics.

Easy integration, high differentiation

Add differentiation to your current mobility technology offerings with line of business facing solutions that can be easily integrated with yours. And we are here to help accelerate time to market by providing integration, training and sales support.

Deploy wherever you want to

Our Cloud-in-a-Box distributions are enterprise ready and can be deployed on public cloud, private cloud or behind the firewall on traditional virtualized environments.

Create beautiful APIs instantly

Our NoServer Datagraph with Virtual Collections automatically generates secure, scalable, full-featured REST APIs and can integrate corporate data and application data seamlessly.
Virtual Collections

Virtual Collections seamlessly integrates application data with corporate data to the device.

A guide for migrating from StackMob to another provider

There have been a number of developments in the Backend as a Service space over the last 12 months, including the acquisition of Parse by Facebook and of StackMob by PayPal with the subsequent announcement of the shuttering of their service on May 11.

If you have an application deployed or in development on StackMob and are looking for a provider replacement, there are a few things that you should consider:

  1. Client-side libraries (SDKs).
  2. Changes to your client code that are required.
  3. Custom code.
  4. Webapp assets.
  5. Migration of your data.

Open Source Baas Test Suite

If you want a good way to compare providers based on a real test suite, Cory Wyles has written an excellent open source test suite the you can use to compare different Baas providers capabilities – on GitHub here. Or, you can read the report summary here.

Client-side libraries (SDKs)

You will obviously need to replace your client-side libraries with the ones provided by your new provider. A few factors to consider that directly relates to the portability of your app.

  1. Support for native classes versus proprietary object classes or protocols
  2. SDK Size and External dependencies.
Native versus proprietary models

Depending upon which devices your current project is targeting, the StackMob implementation will use a variety of object model approaches (iOS – NSDictionary or NSManagedObject, Android – StackMobModel, HTLM5/JS - StackMob.Model which is built upon Backbone.js’s Model) which you will need to replace with the ones specified by your new provider. Most providers require the use of their proprietary object classes or a proprietary protocol. Support for Core Data varies from none to good.

FatFractal is the only provider that support pure, native classes on the client side and is consistent across all devices. Migrating to FatFractal involves removing these proprietary artifacts and replacing them with device native models (iOS – NSObject, NSManagedObject or NSDictionary, Android – Java Object, HTLM5/JS – Javascript Object). This will actually simplify and reduce the size of your application as well.

SDK Size and external dependencies

You will also notice that the size of the SDKs from the various providers range widely in size. The StackMob iOS SDK, for example is 4.5MB in size with 5 external dependencies and others are as large as 23MB with as many as 11 external dependencies. StackMob’s JS SDK requires BackBone.js as a dependency.

FatFractal provides the same or better functionality in our SDKs and is the smallest by far (the iOS SDK, for example is less than 3MB) and with no external dependencies for iOS or JS, with a single dependency on Jackson libraries for JSON serialization/deserialization for Android.  Of course, our JS SDK works perfectly with BackBone.js as well Angular.js or any other as you prefer.

Client code changes

The other changes to your client code involve how you initialize the SDK for your client as well as specific method signatures for interacting with your data. These changes are fairly minor with one caveat – and that is queries. FatFractal provides far more powerful query capabilities which can reduce the number of round-trips that are required to get to the data that your client needs.

Custom code

Stackmob’s custom code provides custom API endpoints for special functions that you require and includes external http request to make external API calls as well as control over how you set the response. Your custom code must be written in Java, Scala or Clojure. Most providers provide a similar capabilities albeit most use Javascript and not Java, but you should check to make sure that the functionality you need is available from the provider.

A key capability you will likely need is access to an http client in order to access external API data.

In addition to custom API endpoints (which we call server extensions, read about them here), access to an http client and email support, FatFractal also provides event based custom code (we call this an Event Handler, read more about them here) which allows for business logic to be included in your application backend. Kinvey now provides a similar capability.

Web app assets and CORS support

If you need to serve up a web version of your application or just an administrative page for your app, then you will want to make sure that your provider provides support for web asset hosting as StackMob does.  Most providers, most notably Kinvey do not offer this functionality!

FatFractal has, from the beginning provided full, easy support for serving up your web assets including CORS support as well as URL mapping.

Data Migration

There are two ways to deal with migrating your data from StackMob to another provider.

  1. Export from StackMob and import to your new provider.
  2. Access the StackMob API directly and move all data via the current API.

There is no right answer to this question, and data migration is always a bit tricky. You should make sure that you can test out the reliability of data migration from your StackMob backend to a new provider to make sure that you will get the results that you want.

FatFractal is happy to help you with either approach – no charge – to make sure that your data can be made available from your new backend easily. Just contact us at Help with StackMob Migration.

A final note – and this pertains to how much control you have over your environment. This post has primarily talked about running your backend on various providers public cloud offering. FatFractal also offers you the ability to run the entire cloud fabric yourself wherever you want – Amazon, Rackspace and even your own servers. We call that Cloud-in-a-Box and you can learn more about that here.

We know that you have many options for where to run your apps. We at FatFractal think we offer all the relevant functionality StackMob does – from core data support to custom code – but also have a number of additional functionality and performance benefits too. On top of that, our developer support always gets rave reviews. So, we’d be delighted if you came to us!

CIB Lite

This blog provides a brief overview of the FatFractal Cloud-In-A-Box Lite (CIB Lite) evaluation, why you would want to kick the tires on it, some instructions on getting started with it, and where we are going with it.

What the heck is this thing?

CIB Lite is a diluted snapshot of the FatFractal Cloud Platform (FCP) that has been packaged into an Open Virtualization Formatted (OVF) image. The image includes a configured operating system (Ubuntu 12.04 LTS), Linux Containers (LXC), FCP, and all the necessary services (i.e., ElasticSearch). The OVF image was generated using VMware WorkStation 10.0.1 and has been packaged as a turnkey environment. We wanted to make the evaluation process as simple as importing the OVF image and powering on the instance and it doesn’t get any easier than that. Another requirement we had was that the evaluator be able to exercise the process from their desktop using a virtualization client. There are several free and pay for virtualization clients available for all the common environments (i.e., Mac, Windows, Linux, etc.), however, we recommend VMware Fusion, Player, or WorkStation as we have tested with them.

From a high level the CIB Lite looks like this -

The FCP has been diluted down to include components such that the following functionality can exercised –

  • Register users
  • Create domain and contexts
  • Deploy fully functional NoServer, Ruby, or Servlet applications
  • View or fetch logs
  • Upload blobs
  • Run the FCP in a fully functional and secure environment

The FCP Dashboard will be included at a later date which will allow the administrator to manage the environment (i.e., LXC, Services, FCP components, and etc.) from the browser.

Why the heck would you want to kick the tires on it?

The CIB Lite was purposely designed to deliver limited functionality in the easiest manner possible to give the evaluator a quick and painless way to kick the tires and decide if they would want to evaluate the CIB Enterprise which is more complicated and has dependencies on infrastructure services.  

Why should the evaluator have to provision a machine (virtual or native) or machines, install something like OpenStack and configure it to simply exercise some of the FCP’s BaaS and PaaS functionality? We figure if the experience with the CIB Lite is a pleasant one and the basic functionality is what the evaluator  is looking for then they will be more compelled to make the investment necessary to evaluate the CIB Enterprise.

How the heck do I get started with it?

1. Download the CIB Lite from here.

2. X-tar and gunzip ovf.tar.gz.

3. chmod -R 744 ovf (not necessary on Windows)

4. Import the ovf into your virtualization client.

5. Power on your VM (created by the import).

Once your VM powers up you will see the CIB Lite splash (next to the Ubuntu login) which will point you to instructions (accessible via the browser) and what your CIB Lite IP address is.

6. On your desktop edit your /etc/hosts (windows C:WindowsSystem32driversetchosts) and add the following entries.

your_cib_lite_ip        acme.ffcib.com

your_cib_lite_ip        system.ffcib.com

We are going to rely on host name resolution via the hosts file.

7. Let’s test the CIB Lite with an existing application.

Point the browser on your desktop to http://acme.ffcib.com/hoodyoodoo/index.html.

If the hoodyoodoo application appears in your browser things are going well.

8. Let’s deploy an application.

8.1 If you don’t have the FatFractal development runtime please download it from here and add the FatFractal_Runtime/bin directory to your path. To test your runtime installation enter ‘ffef’ from the shell command line and you should see the ‘ffef’ options. You will need to create the application that you want to deploy, see the getting started docs for NoServer, Ruby or Java/Servlets apps.

If you do have an existing FatFractal development runtime, rename or remove the .pem file that is located in the conf/ directory.

8.2 In the shell that you will be using to deploy your application add the following variable to your environment.

export FF_FABRIC_DOMAIN ffcib.com

or on windows

set FF_FABRIC_DOMAIN=ffcib.com

8.3 Register an account and create the application domain and context.

Point your browser to http://system.ffcib.com/console/application.html and register. Once you have registered you will be put into a workflow that will allow you to create a domain and context.

8.4 Add the entry below into your hosts file.

your_cib_lite_ip    your_application_domain.ffcib.com

8.5 Enter the command below to deploy your application to the CIB Lite.

ffef deployFFFabric

NOTE: You need to be in the directory where you scaffolded your application.

8.6 Test your application deployment.

Point your desktop application to http://your_application_domain.ffcib.com/your_application_context/index.html

You should see your application appear in the browser.

Where the heck are we going with this thing?

The FatFractal CIB targets specifically Enterprise private or hybrid cloud charters that need BaaS and PaaS functionality. The FatFractal CIB is a public offering battle tested solution that developers love and gives the Enterprise an off the shelf alternative so they don’t have to build the functionality themselves. FatFractal is constantly adding BaaS and PaaS features to their public offering and rolling them back into the FatFractal CIB. Enterprises can only benefit from the existing foundation of the public offering, constant improvements, and the ability to extend the platform for their own special needs.

From a high level the CIB Enterprise looks like this -

Have fun and let us know what you think of the CIB Lite!

- The FatFractal Team -

 

 

FYI – user management – Part I

We get asked a lot about how to customize the user definition (FFUser) with FatFractal. This post describes two methods to add some custom information about the user to the system. Either is fine, and there are some important distinctions regarding access control that you may want to consider. I will be adding more user management use cases in future blog posts. For now, let’s start with the basics and that is subclassing FFUser as well as creating a reference object with the required additional information as an alternative approach.

As usual – I have included source code and a sample application (actually three of them) to further illustrate. For this post, the code is written as test cases and include iOS, Android and HTML5/JS versions.

The source code for the sample applications is here.

A working sample test app is here

Update: Feb 14
Introduced FFUserProtocol – no longer need to subclass FFUser if introducing a custom ‘user’ class – simply have it implement the FFUserProtocol. FFUserProtocol is defined in FFUser.h as follows


@protocol FFUserProtocol
@property (strong, nonatomic) NSString          *guid;
@property (strong, nonatomic) NSString          *userName;
@end

All methods which previously took FFUser as parameters will now accept any class which implements the FFUserProtocol

Method 1: MyFFUser as a subclass of FFUser

The first method is to subclass the FFUser class that is included in all the SDKs. The example here adds three parameters to the definition – including a nickname (String), location (FFGeoLocation) and profilePic (byte[]). The FFUser class can be easily extended to include whatever you want, see the examples below:
[tabs_framed]


public class MyFFUser extends FFUser {
private String m_nickname;
private FFGeoLocation m_home;
private byte[] m_profilePic;

public String getNickname() { return m_nickname; }
public FFGeoLocation getHome() { return m_home; }
public byte[] getProfilePic() { return m_profilePic; }

public void setNickname(String nickname) { m_nickname = nickname; }
public void setHome(FFGeoLocation home) { m_home = home; }
public void setProfilePic(byte[] profilePic) { m_profilePic = profilePic; }
}
// Then just make sure and let the SDK know you want to use this class instead of FFUser
FFObjectMapper.registerClassNameForClazz(MyFFUser.class.getName(), "FFUser");


You can see the full source for subclassing FFUser for Android on GitHub here


@interface MyFFUser : FFUser

@property (strong, nonatomic) NSData *profilePic;
@property (strong, nonatomic) FFGeoLocation *home;
@property (strong, nonatomic) NSString *nickname;

@end
// Then just make sure and let the SDK know you want to use this class instead of FFUser
[ff registerClass:[MyFFUser class] forClazz:@"FFUser"];


You can see the full source for subclassing FFUser for iOS on GitHub here


function MyFFUser() {
this.clazz = "MyFFUser";
this.FFUser = FFUser;
this.FFUser();
this.userName = null;
this.firstName = null;
this.lastName = null;
this.email = null;
this.active = null;
this.profilePic = null;
this.home = new FFGeoLocation();
}
MyFFUser.prototype = new FFUser;

You can see the full source for subclassing FFUser for HTML5/JS on GitHub here

[/tabs_framed]

FFDL definition for FFUser to use MyFFUser additional parameters

CREATE OBJECTTYPE FFUser (userName STRING, firstName STRING, lastName STRING, email STRING, active BOOLEAN, authDomain STRING, scriptAuthService STRING, groups GRABBAG /FFUserGroup, notif_ids GRABBAG /FFNotificationID, profilePic BYTEARRAY, nickname STRING, home GEOLOCATION)
The FFDL definition for FFUser source on GitHub can be found here

Test cases for registering a MyFFUser user

For brevity, I will not include the code for the test cases that will verify that registering a user works properly using the subclass of FFUser. Instead, I will include the links below:
Android test case for registering a MyFFUser user
iOS test case for registering a MyFFUser user
HTML5/JS test case for registering a MyFFUser user

Method 2: PublicProfile class with a REFERENCE to FFUser(MyFFUser)

The second method is to add the additional information to a new Objecttype (my example is called PublicProfile) that contains the same additional information, but also includes a REFERENCE to FFUser. This allows for managing access control for some user information independent of the FFUser which may be useful in some cases. Note – for this exercise, the FFUser still has the expanded parameters, but the sample code only populates the standard info for a user. They point is that you can easily separate what is private and what is more “public”.
[tabs_framed]


public class PublicProfile {
private MyFFUser m_user;
private byte[] m_profilePic;
private String m_nickname;
private FFGeoLocation m_home;

public MyFFUser getUser() { return m_user; }
public String getNickname() { return m_nickname; }
public FFGeoLocation getHome() { return m_home; }
public byte[] getProfilePic() { return m_profilePic; }

public void setUser(MyFFUser user) { m_user = user; }
public void setNickname(String nickname) { m_nickname = nickname; }
public void setHome(FFGeoLocation home) { m_home = home; }
public void setProfilePic(byte[] profilePic) { m_profilePic = profilePic; }
}


You can see the full source for the PublicProfile class for Android on GitHub PublicProfile class with REFERENCE for Android


@interface PublicProfile : NSObject

@property (strong, nonatomic) MyFFUser *user;
@property (strong, nonatomic) NSData *profilePic;
@property (strong, nonatomic) NSString *nickname;
@property (strong, nonatomic) FFGeoLocation *home;

@end


You can see the full source for the PublicProfile class for iOS on GitHub PublicProfile class with REFERENCE for iOS


function PublicProfile(obj) {
if(obj) {
this.user = new MyFFUser(obj.user);
this.profilePic = obj.profilePic;
this.nickname = obj.nickname;
this.home = new FFGeoLocation(obj.home);
} else {
this.user = new MyFFUser();
this.profilePic = null;
this.nickname = null;
this.home = new FFGeoLocation();
}
}

PublicProfile class with REFERENCE for HTML5/JS

[/tabs_framed]

FFDL definition for PublicProfile with REFERENCE to MyFFUser(FFUser)

#Objecttype definition
CREATE OBJECTTYPE PublicProfile (user REFERENCE /FFUser, profilePic BYTEARRAY, home GEOLOCATION, nickname STRING)
# Permission setting
CREATE COLLECTION /FFUser OBJECTTYPE FFUser
#PERMIT read:system.admins write:system.admins ON /FFUser
CREATE COLLECTION /PublicProfiles OBJECTTYPE PublicProfile
#PERMIT read:loggedin write:system.admins ON /PublicProfile
You can find the FFDL definition for PublicProfile on GitHub here

Test cases for registering a FFUser(MyFFUser) user and creating a PublicProfile

For brevity, I will not include the code for the test cases that will verify that registering a user and creating a profile object works properly. Instead, I will include the links below:
Android test case for registering a FFUser(MyFFUser) user and creating a PublicProfile as well
iOS test case for registering a FFUser(MyFFUser) user and creating a PublicProfile as well
HTML5/JS test case for registering a FFUser(MyFFUser) user and creating a PublicProfile as well

Hope that you find this useful…

Kevin

TechEmpower and Servlets

This blog article is Part One of a two part set of articles that provides an overview of our Servlet module and its performance as compared to a conventional Servlet container, Tomcat. This article will focus on the design differences between the containers and then provide an overview of the TechEmpower test suite which will be used to compare the performance. The TechEmpower folks have done a bang up job of benchmarking different frameworks and in the process have created a standard test suite that is comprehensive and exercises functionality that you would typically find in a production environment. Rather than reinvent the wheel I have decided to leverage the TechEmpower test suite with a couple minor changes. Part Two (which will be available in a couple weeks) of this set of articles will focus on the results and hopefully :-) provides some insight that explains them.

FatFractal (FF) Application Container aka Engine

Before jumping directly into the FF Servlet module I thought it appropriate to provide some background on the FF Application Container or as I commonly refer to it, the engine. The engine is really just an NIO server that has support for pluggable protocol handlers (and modules which I’ll cover next). The basic operations of the engine are very straightforward which drill down to read (and write) data as quickly as possible and chunk it to the protocol handler. The FF HTTP protocol handler is event based (think node.js) and will continue consuming data until it detects that it has received a full HTTP request, at which point it publishes it to subscribers.

Once the protocol handler detects that it has received a complete HTTP request, it is published  and one of the subscribers is a module delegator. The module delegator is responsible for delegating the request to the module that is managing the application. A module is essentially a software stack (i.e., Servlet) that is responsible for executing the application. So there is a complete decoupling of the network I/O and application execution. A given engine can host multiple modules (i.e., NoServer, Ruby, Servlet, etc.) and a module can host multiple applications. For PaaS applications (i.e., Ruby, Servlets) an engine will typically host one module which will host one application and the engine will run within an LXC container for security reasons. Currently modules are run in the same JVM as the engine, however, that may change in the future so that a single NIO engine can publish requests to multiple modules that reside in their own LXC containers on the same VM or on other VMs.

FatFractal (FF) Servlet Module vs Conventional Servlet Container

The FF Servlet module is a very lightweight Servlet Container that supports the typical things you would expect such as JSPs, listeners, filters, and etc. It was purposely not designed to be a full blown Servlet container like Tomcat and is available for developers that want to use the framework to implement their server side functionality. The biggest difference between conventional Servlet containers and the FF Servlet module is that the network I/O has been decoupled from the framework. A typical Servlet application can get access to the socket streams through the HttpServletRequest and HttpServletResponse objects. The FF Servlet module provides access to those streams but the streams are implemented as encapsulations around buffers. This decoupling of I/O from the frameworks is what allows a single engine to support a truly polyglot environment and will allow FF to extend its language/framework support using a single software stack.

TechEmpower

As previously mentioned the TechEmpower folks have constructed a test suite that consists of tests that exercise different aspects of the frameworks. This article will employ the following three tests:

  1. JSON serialization
  2. Database access (single query)
  3. Database access (multiple query)

JSON serialization

In this test, each HTTP response is a JSON serialization of a freshly-instantiated object, resulting in {“message” : “Hello, World!”}.

Database access (single query)

How many requests can be handled per second if each request is fetching a random record from a data store?

Database access (multiple query)

The following tests are all run at 256 concurrency and vary the number of database queries per request. The tests are 1, 5, 10, 15, and 20 queries per request.

This article will use the same client (WeigHTTP) that TechEmpower used and the same EC2 configuration. TechEmpower typically tests on both EC2 and on dedicated hardware, unfortunately :-( I don’t have the latter and will only perform the tests on EC2.

While this article will only be comparing the FF Servlet module and Tomcat, the results can also be compared to the TechEmpower framework results since the same tests, client, and EC2 configuration are being duplicated.

Okay over and out and see you soon with the results.

Contact