Login if you already have an account



Create a new account. join us!



Need some help? Check out our forum.


How James Paulin built a game from scratch in 72hrs using FatFractal’s backend.

Every so often we get contacted or tweeted at by FatFractal users about how our platform was able to benefit them in various scenarios. This is a story about a hobbyist indie game developer from Oxford, UK called James Paulin -
(t: @jimmypaulin).

James went on Ludum Dare – a website that  gaming development competitions – and was challenged to compete and develop a game from scratch in 72hrs.

As you know, building a functional game from scratch can be a very intensive process. Not only do you have to write and develop the code for all the functionality and mechanics,  you will also need to spend a decent amount of time designing the game to make it look good or at least visually passable – keeping in mind the 72hr time frame. An important part of development you cannot overlook however is having to set up and deploy the backend to make it all work across the wire.

James is not a full time game designer. He is a father, a family man, with a day-job in IT. Writing boilerplate backend code is a well-known tedious task. Telling a computer how to process and handle data is extremely important yet is very repetitive and dull. The reason he was able to pull through the development process and keep it within the time frame was the ability to set up a working backend in a fraction of the time and effort it usually takes.


The game, called Trappy Tomb, takes place in an Indiana Jones/Tomb Raider style environment viewed from a top-down perspective where the ghosts of previous players haunt you as you play. The app scaffold for the game was done in advance, then all it took to get up and running was to hook-up JavaScript callbacks in the game engine. James said “It took 45 minutes to get it all up and running. It was very fast, it just works”. Once the backend was deployed, he added the object model into the game and that was it. “It was an early boost that helped in the competition.” he said.

At this point James was able to better focus on the Client Side of things, the more important parts of development, the fun stuff! He was now able to give more time to developing the functionality and design of the game. The end result scored highly on innovation points but also scored well for gameplay and graphics. Other contestants were intrigued by his unique Client-Server-based setup, and are interested in testing and using the FatFractal platform for this very reason. James wrote a postmortem about the whole process on his SuperFluidGames blog.

He had previously experimented with the FatFractal platform back in January after he found a written article about FatFractal on Ray Wenderlich’s website. He then recently came across a simple tutorial on the FatFractal Github that showcases the platform’s abilities.

Quoting James: “I chose FatFractal for the server backend and it worked really well. It doesn’t require much setup at all and there is no Server Side code needed. You simply log-in a user and push your objects to the server. You can then pull them back with a rich query language.”


One of the issues James was curious about is Scalability. Without warning, his game picks up across the web and suddenly he notices a huge spike in the number of users playing the game. Without panic, or the need to take the game down, Trappy Tomb was instantly and automatically able to handle all the extra load without experiencing any hiccups, thanks to FatFractal’s proficiency in scalability.


This is usually a dreaded part of development. Ensuring that your application will run securely over the wire without fear is not an easy task. James’s concerns are derived from the MySQL injections he previously had to handle. “I am not a system admin and have no experience with network coding and internet security. Having to write custom solutions for cryptography and secure user accounts – its so boring.” he said. “It gave me free time to do the fun stuff. Shove the data up to the server and use the FatFractal rich query language in a string and get a bag of data back down. Love the rapid tight loop around that. It’s very appealing, and takes the pain out of worrying about capacity, scaling, and security.” he added.


The FatFractal customer support has always been one of our best qualities mostly thanks to our resident software engineer Gary Casey.

Here’s James’s scenario (in his own words):

* Open to abuse. I really should have seen this coming, I really should, but I figured it was unlikely that the game would make it outside the Ludum Dare community and so everyone would ‘play nice’ with their comments. Alas it was not to be and on one occasion I was confronted with some extremely offensive language that caused me to take the game offline immediately. It took a few days to work out a solution and thanks go to Gary at FatFractal for his support (t: @gkc). I settled on a system whereby all comments are immediately added to the local game, but will not appear in anyone else’s game until I’ve moderated them via a holding area. This actually has the side benefit that I can read all the comments as they are added.”

This development scenario is not one that’s unheard of. Developers will usually have to battle bugs, overcome security problems, and power through all obstacles to make a piece of software work properly. The FatFractal platform is always there and ready to give your app a solid kickstart.

In the end, James came in 14th place out of 1045 entries in the 72hr jam! He has plans to continue developing Trappy Tomb into fully fledged iPhone and iPad apps. Keep an eye out for it.

In the mean time, get started here with a backend for your app for FREE.

Truth In Code


FatFractal ups the ante in Backend-as-a-Service market

Anyone who has developed a smartphone app would have set up servers and built backend services such as location services to support the app. You could do this on your own servers, or tap on IaaS and PaaS providers like Amazon Web Services (AWS) and Cloud Foundry.

But whether you choose to build and host your app in-house or through the cloud, you’d still need to deal with social media integration and set up virtual machines, user profile services, and more.

The Market:

In the past year, a handful of startups have formed a new category of cloud services known as backend-as-a-service (BaaS) to ease the task of setting up the nuts and bolts for running mobile apps. The new players such as Kinvey, Parse, CloudMine and more recently, FatFractal, all provide mobile backend services such as data storage, push notifications and user management.

“The BaaS players are providing application developers with an instant backend so that they don’t have to manage one,” says FatFractal’s chief marketing officer David Lasner.

While developers can turn to the likes of AWS to build a mobile backend, they have to configure their cloud infrastructure extensively, such as defining an event model that triggers what happens when a user, say, checks in at the same location several times a week.

“And you’re wiring it all together every time you want build an application,” Lasner says.

What we were looking for is something that would give you the native code support, an event model and security that works, so you can stop using the heavy stuff on the enterprise side. You have some pretty smart people out there, but it was still incredibly hard to build these cloud-based apps. That’s why we built the FatFractal platform,” he adds.

Upset the Status Quo:

The new BaaS offerings have the potential to upset the status quo in enterprises that typically control who develops apps and how apps should be developed, says FatFractal’s president Kevin Nickels.

“At the strategic level, they should think about how every employee should be able to write an app, or that customers should be able to write their own apps and access corporate information they way they want to. That’s a really hard thing for an IT department to wrap its head around,” he says.

According to Lasner, FatFractal took about two years to build and allows programmers to write applications in native environments such as Java and Objective C.

“You’ll also get out of the box services integrated in your object oriented world that allows you to do some complex modeling,” he says, “I often joke that if the Facebook team used the FatFractal platform, all the problems they had with the privacy of photos and groups would have taken a month to resolve.”

FatFractal also provides access into the backend, which not all BaaS players allow, according to Lasner. “That’s a problem because if you’re going build a software architecture for the cloud, most of the heavy lifting should happen on the backend. So, while it’s great to not think about data stores, I also want my business logic, events model and custom code to run on the backend”.

As an engine-based platform, FatFractal also allows developers to use familiar technologies to write apps and run the platform, including data stores and services, locally on their own PCs before deploying to the cloud. “Developers love to build things on their own machines because all the tools they’re using are available there, and you don’t have to rely on a network.”

A concern among companies considering BaaS services is the risk that service providers could change pricing models or go bust. Lasner assures developers that there is no vendor lock-in with FatFractal, as the platform uses the same data models in standard programming languages such as Java. That means you can move your app to another infrastructure service or platform, Lasner says.

How developers will take to FatFractal and the other BaaS offerings remains to be seen. After all, to developers, IaaS, PaaS and BaaS are merely different parts of the larger cloud infrastructure required to run their apps.

As Nickels puts it, “there is no need for BaaS to be separate from PaaS; there are no separate markets and at some point, they are going to collapse into a single definition”.

By: Aaron Tan

Permissions can be inherited from other objects (pretty slick!)

As a Developer, I want to be able to implement access control policies that are inherited from another object so that I can easily propagate access control policies within my application.

If you want to set a default permission for objects in a collection that inherit permissions from another object, it is super easy using FFDL (what is FFDL?).


Say you have a Collection of JokeBook objects with permission defaults set and another Collection of Joke objects that have a reference to a JokeBook and you would like your Joke objects to inherit their default permissions from JokeBook objects. OK – short version is that I want the permissions for a Joke to be the same as the JokeBook they refer to.

The FFDL would look something like:

# JokeBook
CREATE OBJECTTYPE JokeBook (title STRING, writers REFERENCE /FFUserGroup, readers REFERENCE /FFUserGroup)

PERMIT read:object.readers write:object.writers ON /JokeBooks

This defines a JokeBooks Collection that contains Jokebook Objects that have a title, a reference to an author, a reference to a group of users with write access named writers and a group of users with read access named readers.

# Joke
CREATE OBJECTTYPE Joke (setup STRING, punchline STRING, book REFERENCE /JokeBook)


PERMIT read:object.book.readers write:object.book.writers ON /Jokes

This defines a Jokes Collection that contains Joke Objects which have a reference called “book” from the JokeBooks Collection:

book REFERENCE /JokeBooks

So, you will notice that read and write permissions for a Joke object are set to refer to the read and write permissions (respectively) that are defined for the JokeBook object referred to by the “book” member.

PERMIT read:object.book.readers, write:object.book.writers ON /Jokes

Voila! Now the Joke object has the same permissions as the JokeBook object – as easy as that!

Of course, this is the default setting and you can always change the access to any particular object programmatically in your application code.

Hope you find this useful!!

For more details, see the FFDL documentation here.

To see the other things you can do with permissions see here.

Why the name FatFractal?

People always ask us for the meaning behind the name “FatFractal”, so we decided to write a blog post about it!

We wondered, “why is it so difficult for developers, like us, to find a platform that makes it easy to create compelling apps with a cloud backend?”

The Backbone of FatFractal -

We could not find an end-to-end solution with everything we needed: native code support for any connected device, an events model, declarative security, custom code and all of those things integrated as lightweight services. Everything had to be elegant, easy-to-use, intuitive and delightful.

The underlying platform needed to be engine-based for dynamic scaling, to support any infrastructures, to have a published services model and to be able to support any languages, backend and frontend. We liked developing on local machines and insisted on deploying to the cloud without reconfiguration. And we wanted it all to be boilerplate free and reasonably priced.

Since we couldn’t find it, we built it - 

When we named the company FatFractal, we had in mind the intersection of the exploding mobile apps space, our technology platform and the cloud. The heart of our platform is a small, simple engine. Since all applications, modules, components and services on the platform have FatFractal engines at their core, some techie-types might call the resulting topology a fabric.

The reason behind the name -

The metaphor we like best is the fractal: the engines at the heart of services are self-similar, components that replicate and scale in a fractal-like pattern. As the fabric expands, emergent properties of the system can be both surprising and compelling. As apps, services, components, threads and IaaS’s are added in, that fractal-like fabric scales fast, getting as vast–or as compact–as it needs. We continue to believe that the cloud is more like a fractal than a…um…cloud.
Hence, the name: FatFractal

FatFractal Provides the Software To KickStart Your Idea. 

DevRev is the Community that Tells Your Story.


There are a number of barriers that prevent developers from getting going on developing apps. Frequently, this means that they need to find a backend engineer and/or a DevOps engineer to work with before they can even get started, and those resources are hard to find.

If you don’t already know, FatFractal is a company that is passionate about removing barriers that inhibit new startups from getting their ideas to market as fast as possible. By providing a public cloud platform, FatFractal helps you get your product working in record time.


The notion behind being able to build your product from just an idea and take it to market as fast as possible with the least amount of hurdles is something we strongly believe in.

Entrepreneurs, Innovators, and Idea Generators are all individuals who fall in that category. Idea Generators especially will relate to that category. Lots of people have ideas, not many actually do something about it.


They simply don’t know where to start –  

“I have a great idea! but no clue on what to do with it”. The thought process of turning an idea to a product can be daunting to certain individuals, especially when it exists outside of their field of knowledge.

They’re afraid of FAILURE -

The word “failure” above is in all-caps because thats how much people get intimidated by the idea of it. A common trend you will notice among successful people is that they are never afraid to fail. Valuable lessons can be learned from failure.

They don’t like the feeling of uncertainty -

This is different than fear of failure. It’s an aversive state that generally we try to escape from. Unfortunately creativity requires uncertainty by definition, because we’re trying to do something that hasn’t been done before.



DevRev is an open, online conversation with shared stories about the problems that entrepreneurs face as well as innovative solutions that others have created to solve them. If you are, or want to be an entrepreneur, then come share your story so that others can benefit from your experience and share their experiences with you.

We believe that entrepreneurs are the engine of the future more now than ever.
We are driven by a passion to accelerate the process of getting from an idea to market success faster and better. Everything we do is intended to identify barriers that inhibit innovation and create a community to smash them.

What we have created, is an online community to research the problem areas that get in the way of creating great things, and look for ways to radically improve them.


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.

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 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.
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) {
}, function(error) {
console.log("Oh crap", error);
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});
parseFile.save().then(function() {
var note = new NoteOb();
note.save(null, {
success:function(ob) {
}, error:function(e) {
console.log("Oh crap", e);
}, function(error) {
} else {
var note = new NoteOb();
note.save(null, {
success:function(ob) {
}, error:function(e) {
console.log("Oh crap", e);
(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)

Here’s a set of Objective-C interfaces:

@interface Movie : NSObject
@property (strong, nonatomic) NSString *movieName;
- (void) getTheaters:(id )delegate;
@interface Theater : NSObject
@property (strong, nonatomic) NSString *theaterName;
@property (strong, nonatomic) FFGeoLocation *location;
- (void) getMovies:(id )delegate;
- (NSError *) addMovie:(Movie *)movie;
@protocol SimpleLoadProtocol
- (void) didLoad:(id)data;
- (void) didFailLoadWithError:(NSError *)err;

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];
[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)
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];
[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)
Data set: showing relationships
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