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

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

Contact