Login if you already have an account



Create a new account. join us!



Need some help? Check out our forum.

Welcome to our Blog

The Post

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

Enterprise In The Cloud

The Enterprise and Cloud

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

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

Wait out the storm

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

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

Some Numbers

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

Enter FatFractal:

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

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

Speaks your language

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

Public cloud

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

Private cloud

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

Pick the bits you want

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

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

Leverage corporate data

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

Integration support

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

Get the most out of your mobility infrastructure

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

Easy integration, high differentiation

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

Deploy wherever you want to

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

Create beautiful APIs instantly

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

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