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

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.

Setup:

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.”

Scalability:

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.

Security:

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.

Support:

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

Announcing Cloud-in-a-Box 2.0

Introduction

A week or so ago I read an interesting blog article written by Sravish Sridhar from Kinvey. The core message behind the blog article was that both Infrastructure-as-a-Service (IaaS) and Platform-as-a-Service (PaaS) players are increasingly offering Backend-as-a-Service features but their implementations lack key services which are critical to enterprise mobile charters.

Kinvey entered the BaaS market at about the same time FatFractal did and the features you find in each respective offering are very similar, although I believe FatFractal has a much stronger API and data story, but hey I’m not biased right :-)

Both companies started with public offerings and have increasingly transitioned their focus to the enterprise.

While I think Sravish did a great job on his assessment of what BaaS services are needed by the enterprise, I think there is a broader story to be told because in many enterprise engagements the offering needs to be installed behind the firewall (or on a private cloud), IT needs tools to effectively manage, monitor, secure, and scale it, and developers need services to leverage it.

This blog article will focus on the FatFractal Cloud-in-a-Box (CIB) offering which addresses the latter concerns and to a minor extent on the patented FatFractal NoServer offering which is the FatFractal BaaS stack.

How do NoServer and CIB fit together?

I thought it might be useful to quickly provide short descriptions of both NoServer and CIB so that they don’t get all jumbled up and then how they work together.

NoServer is a highly configurable BaaS software stack that is responsible for processing mobile app client REST requests. The NoServer software stack can be configured using a declarative metadata language that is defined with the FatFractal Definition Language (FFDL) file. The FFDL file is very powerful and allows the developer to define collections, impose security and permissions, define custom Javascript server extensions (functionality beyond the basic BaaS CRUD), and much more. If you want to learn more go here.

The CIB is a container (LXC) management platform built on top of docker.io. Each discrete stack, whether it be an API/application (i.e., NoServer, node.js) or service (i.e., MySql, ElasticSearch) stack runs in its own container. The containers, as well as other CIB artifacts (i.e., images, stacks), can be managed through an IT dashboard. The CIB is a tool that allows IT to standardize stack deployment, administration, monitoring, security, and scaling.

So NoServer is a BaaS stack that runs in a CIB container and the combination delivers an enterprise grade mobile platform that provides IT and developers with the tools and services they need to quickly address organizational needs in market time frames.

Why docker.io?

So why did FatFractal select docker.io as the plumbing to its CIB offering? Unlike the FatFractal public footprint up on Amazon, which uses native LXC, the CIB will typically be installed and administered by an IT person into their own environment behind the firewall or onto a private cloud. Docker.io provides both a command-line interface (CLI) and REST API that both provide similar functionality and is facilitated by the docker.io daemon.

The CIB installer creates a collection of containers using the CLI and the IT Dashboard provides container/image administrative functionality by interfacing with the CIB D-OSGi administration services which encapsulate the docker.io REST API. So docker.io provides the CIB with a standardized approach to installing, managing, and scaling its footprint.

In addition docker.io provides the following benefits -

  • Isolation of stacks: On a given host/VM you will typically run a myriad of application and service stacks and containers provides an insulated and standardized process for accomplishing this, minimizing potential conflicts.
  • Security: Containers allow you to sandbox ap­pli­ca­tions reducing the risk to the whole host/VM.
  • Testa­bil­i­ty and re­pro­ducibil­i­ty: Packaging ap­pli­ca­tions into containers guarantees they will run as tested independent of where they are are deployed.
  • Containers: minimizes the pain of say maintaining QA, staging, and production environments across multiple hosts/Vms. In addition when you need to upgrade a component in the container it is fast to run the upgrade, test the resulting container and deploy the diff of the new image to your hosts.
  • Limit resource usage: Docker makes it easy to limit the CPU and memory available to an ap­pli­ca­tion. This way a rogue process or a traffic spike on your blog won’t nec­es­sar­i­ly bring down your whole VM.
  • Upgrading / down­grad­ing / ap­pli­ca­tion versions: Containers makes application management consistent and straightforward simply by maintaining multiple containers.

So while docker.io is not a panecea, it was the best framework for the CIB plumbing.

Why does the enterprise care about CIB?

As mentioned earlier, CIB is built on top of docker.io and provides higher-level functionality such as browser-based administration, monitoring, scaling, application routing, push button application and stack deployment, etc. Docker.io is a fantastic tool but to be leveraged effectively in an enterprise environment it invariably needs to be encapsulated into higher-level tools.

Below are some potential enterprise use cases:

How would IT use CIB.

  • IT would use CIB to provide standardized environments for their development, QA, and production teams, thus eliminating the headaches associated with developing in disparate environment (“It works on my machine…”).
  • IT would use CIB’s dashboard to administer, monitor, and scale applications through container management.
  • IT would use CIB’s private registry to publish images so they can be accessible across the organization.
  • IT would use CIB’s dashboard to create pools of containers (virtual clouds) accessible to only those users that have been provided permissions.
  • IT would use the standard Dockerfile format and CIB’s dashboard stack management functionality to define and deploy new stacks.
  • IT would use CIB to build high availability distributed footprints.

How would developers use CIB?

  • Developers can build any app in any language using any stack.
  • Developers would use CIB’s console for push button application deployment.
  • Developers would use CIB’s console to debug and monitor their applications.

How would the enterprise benefit from CIB/NoServer?

  • Turn-key enterprise-grade mobile platform.
  • Faster application development.
  • A standardized environment for all internal and external development and deployment.

So the CIB is really one of those build or buy it propositions where the enterprises can roll their own docker.io implementations or leverage a platform like the CIB.

What do I get with a CIB?

The CIB consists of several components all of which are deployed as containers that can be distributed across multiple hosts/VMs. These components provide some level of scope as to what is necessary to roll your own docker.io implementation and have a platform similar to that of the CIB.

Banner-1-1024x560

 

 

 

 

 

 

 

 

 

 

 

 

IT Dashboard

The CIB dashboard provides IT with web based functionality it needs to administrate hosts, pools, services, containers, stacks, and images. IT never has to deal directly with docker.io or infrastructure services, everything necessary can be accomplished through the dashboard.

 

Dashboard

 

 

 

 

 

 

 

 

 

Configuration

Configuration allows IT to configure the CIB for such things as ActiveDirectory access, infrastructure services access (i.e., AWS, OpenStack, etc.), blob store access (i.e., S3, Swift, etc.) etc. It also allows IT to configure CIB containers (i.e., MySQL, Zookeeper, etc.) which are used by the CIB administrative services.

Hosts

Hosts provides access to compute infrastructure services (if available) for such things as spinning up a new EC2 instance through AWS.

Pools

Pools allows IT to create virtual clouds that consist of containers that can only be accessed by permitted users. An example use case would be development pools for supporting the application life cycle such as test, staging, and production pools. Pools can be quickly cobbled together by assigning containers to them and then giving permission to users or groups of users. An example use case would be that marketing has hired a couple mobile developers to crank out a temporary campaign app which will only be needed for a short period of time. IT can simply create the pool, containers, and then permit those developers access to that pool and delete when it is no longer needed, which releases all resources (i.e. containers).

Services

Services are used to define service dependencies for application stacks. For instance, when the FatFractal NoServer stack was defined it declared it had a dependency on two services; 1) MySQL and 2) ElasticSearch. So when a new container is created with the NoServer stack it must be assigned to a pool that has those services available.

Containers

Containers provides comprehensive management functionality that allows IT to create, monitor, delete, start, stop, inspect, and etc. containers. Typically IT will create a set of containers using a variety of stacks and assign them to a pool.

Stacks

Stacks allows IT and developers to construct whatever kind of application or service stack they wish. Those stacks will subsequently be used to create images. A typical stack will consist of a Dockerfile and associated artifacts (i.e., configuration files).

Images

Images are use to create containers.

Administrative Services

The CIB administrative services are implemented using D-OSGI that are packaged into a container. The CIB administrative services are published to Zookeeper and subsequently discovered and fetched by consumers. The administrative services can be deployed anywhere and multiple containers can be started providing protection against failover.

 

Administrative

 

 

 

 

 

 

 

 

 

 

 

 

Infrastructure Services

If infrastructure services are available, the CIB dashboard can be configured to use them and provides access through the Hosts menu selection. Access to all infrastructure services is facilitated through JClouds. The Hosts menu selection provides functionality for starting, stopping, and terminating instances. When an instance is started it is bootstrapped with a node install script that installs such things and the Docker daemon, the CIB agent, etc. The intention is not to replace the things like the AWS console but rather provide convenience functionality for managing hosts where containers will be installed.

 

infrastructure

 

 

 

 

 

 

 

 

 

 

 

 

CIB Director

The CIB director is responsible for routing and load balancing requests to application containers. When an application is deployed, its container is registered with the director and any subsequent requests are routed to that container. If the application is deployed across multiple containers, the director will load balance requests across the containers.

FatFractal CIB

 

 

 

 

 

 

 

 

 

 

 

 

User Defined Stacks

IT and/or developers can define custom stacks which can then be used to create images and containers. The process for doing so is relatively simple and involves creating a stack build artifact. The stack build artifact is a tar file that contains a Dockerfile and associated artifacts at its root. Once the stack build artifact has been created it can be uploaded through the IT dashboard using the ‘Create Stack’ menu item. Once the stack has been created it is available to create an images and containers.

Below is the Dockerfile used to create the Mysql service stack used by the NoServer stack-

FROM ubuntu:14.04

MAINTAINER Mic Holst <mic@fatfractal.com>

RUN apt-get update -qq

RUN ln -s -f /bin/true /usr/bin/chfn

RUN apt-get install -y –fix-missing mysql-server

ADD my.cnf /etc/mysql/conf.d/my.cnf
RUN chmod 664 /etc/mysql/conf.d/my.cnf
ADD run_mysql /usr/local/bin/run_mysql
RUN chmod +x /usr/local/bin/run_mysql

VOLUME ["/var/lib/mysql"]

EXPOSE 3306

CMD ["/usr/local/bin/run_mysql"]

CIB Developer Console

Dashboard

 

 

 

 

 

 

 

 

 

The CIB developer console provides access to containers in pools the developer has been permitted to access.

The CIB console provides the following functionality -

  • Deploy applications.
  • Fetch application logs.
  • Fetch application analytics.
  • Start and stop applications.
  • Monitor applications.

Conclusion

So I think Sravish was spot on as it applies to what type of BaaS services the enterprise needs, however, the enterprise also needs a robust and scalable platform off which to serve those services. There are several platform solutions in the market that address the enterprise including but not limited to the CIB, CloudFoundry, Stackato, WSO2, etc. At FatFractal we think we have a winning combination in the NoServer BaaS stack and CIB, everything that is needed to truly build an enterprise grade mobile solution.

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?).

Example:

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)

CREATE COLLECTION /JokeBooks OBJECTTYPE JokeBook
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)

CREATE COLLECTION /Jokes OBJECTTYPE Joke

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.

WHY FATFRACTAL?

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.

WHY DEVREV?

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.

WHY YOU ASK? HERE ARE OUR THOUGHTS ON THE MATTER:

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.

 

ENTER DEVREV:

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.

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!

Contact