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

Lovin’ Localhost

When you set up for local development, you install a fully-featured FatFractal Engine on your desktop. This is not a crippleware version, not a simulation.

Assumption: Developers want to build, test and manage their backend, from start to finish, in the cloud. That’s what we thought because that’s the functionality other well-known platforms were providing, even insisting on. Configure a sandbox in the cloud with your backend, create an app locally, deploy to cloud, test, fix backend issues in the cloud, repeat. When you think you’re done, deploy to production environment.

Turns out, not so much. Many developers much prefer to build apps—backend included—locally. It’s faster and much more efficient. It’s more reliable than having to compile, deploy, and tweak over the internet. That is, if you even have network access. Locally you can run in foreground to the console or in daemon mode to tail the log. Especially in the early stages, you can do quick debugging. The whole process stays “snappy.”

So why don’t developers always build the backend locally and then deploy to the cloud when they’re done?

Simple: the cloud environment is either not available or operates just differently enough to diminish any value in using it locally. Developers can’t depend that what works on http://localhost/, even if they have that option, will work the same when they deploy their backend to the cloud. Some vendors provide a simulator which is almost like their deployment environment, but not nearly close enough—when you deploy, it can be a painstaking process to figure out what’s going wrong.

The FatFractal platform was built on an engine model. We believe that during application development it is imperative to have the local runtime environment be a carbon copy of what’s up on the cloud.  When you set up for local development, you install a fully-featured FatFractal Engine on your desktop. This is not a crippleware version, not a simulation.

The desktop version is pre-configured with the NoServer module, but should a developer want say, Ruby, the module delegator will dynamically download the appropriate module when the application is locally deployed to the FatFractal Engine. You can configure the local engine during installation or after that with such configure common properties such as the HTTP port and deployment scanning interval. Certain non-applicable features such as infrastructure services are deactivated; but that doesn’t change the functionality of the FatFractal Engine one bit.

You can deploy as many applications locally, as many times as you want. Once your app is fully-tested on your dev machine, including all of the application’s events, custom code and services, you can deploy to the cloud (the FatFractal Fabric) with one simple command line instruction: ffef deployFFFabric

And you can be confident it’s going to work the same way in the cloud as it did locally.

Wherefore FatFractal?

 When asked, is FatFractal a PaaS or a BaaS, a cloud services company or a cloud API provider? I reply, yes, yes, yes and yes.

The technology world has embraced the cloud.

As with most paradigm shifts, change has been gradual, starting with the virtualization of some well-established enterprise IT-driven stacks behind firewalls. The first cloud implementations moved those same stacks, to the cloud. Lots of exciting movement in the open source world was a big step. Still, we think cloud based architectures have a ways to go: there are still lots of dependencies and configuration headaches in setting up a backend. Moreover, the conventional stack-in-the-cloud means you’re often bound to a specific infrastructure.  That’s good for the vendor, but not always for the developer.

The rise of PaaS’s to abstract the infrastructure layer has been dynamic, with major players and lots of up-and-comers…any language you can think of, lots of great, backend services. Configuring and maintaining stacks can still be a big pain in the backend, but sometimes you can actually act as if you’re deploying to an integrated, pretty-much-configured platform. As long as you can manage some backend code and as long as that vendor is exposing the services, languages, scalability and performance you need, at the right cost, it’s great. Sometimes a bit tricky to get out, though, once you’re in.

BaaS has recently staked a perimeter around mobile apps and their backends, making it easier for developers to create them. BaaS solutions are constrained; but if you’re doing a straightforward app, with a fairly simple backend, these BaaS’s can be compelling. Better than a static app on that smart phone, for sure!

As we looked at the evolution of the cloud, from cobbled-together enterprise IT stacks, bringing in open source components, to super-powerful middleware, to simple backend services, we asked ourselves a question: what do developers need in a platform, end-to-end, to create compelling, cloud-based apps for any connected device?

Here’s what we came up with and it all centers around what a great, app architecture requires for the cloud:

Day One Design Requirements
  1. An engine-based, highly-scalable, lightweight, services-oriented platform.
  2. An app should run identically on your local machine or in the cloud. 100% fidelity.
  3. Create a backend, available to any connected device, without boilerplate drudgery.
  4. No lock-in on your data, infrastructure or code.
  5. Platform SDKs must result in efficient, elegant code: you should be delighted.
  6. Your app’s CRUD events can be exposed to event handlers on your backend.
  7. Extend your API with custom code, often critical for cloud-based apps.
  8. Use JS or any language you want for your API extensions and event handlers.
  9. Use our services for common things like authentication, groups, login, and geolocation.
  10. Model social-networks and complex datagraphs, easily, even lots of many-to-many relationships.
  11. Process nested, complex queries and traversals on the backend.
  12. Change permissions by default or at runtime on collections, objects or members.

These design requirements drove the development of the FatFractal Platform: we built a solution that cuts across several traditional IT boundaries, because that’s what developers have to have to build great apps with a cloud backend.  When asked, is FatFractal a PaaS or a BaaS, a cloud services company or a cloud API provider?

I reply, yes, yes, yes and yes.

Message from the Coder & Chief

I am pleased to announce the FatFractal public beta. Thank you to our team, investors and coder/partners: we are indeed fortunate.

I am pleased to announce the FatFractal public beta. Thank you to our team, investors and coder-partners: we are indeed fortunate.

Like everyone, we are captivated by the world-changing “sense of possibility” inherent in the cloud. As with most paradigm shifts, change has been gradual, mostly made up of repurposed legacy technology and processes, borne out of enterprise IT. Although some of the steps along the way are rather shameless applications of a cloud veneer to legacy tech, it’s a well-understood evolution, slow and gradual. We believe many of these first steps, led by smart people, will eventually get to good answers.

We, however, are a bit impatient. When we couldn’t find a system that did what we wanted right now, we ended up building one, from top-to-bottom.  We hoped to make a leap forward, rather than making incremental improvements. Whether we succeeded, of course, will be yours to judge.

Our purpose (legacy word = ‘mission’) is to offer a solution to coders who face the same challenge we did: is there a platform out there for developing native apps with cloud backends, for any connected device, end-to-end, easily and efficiently? Oh yeah…and at the lowest, possible cost. That’s a big one!

We invite you to check us out and see what we built, originally for ourselves, and now, for you. We can’t wait to hear what you think.

Contact