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.