Why F(x)
Building extendable web applications, where developers and/or users have the option to securely extend the capabilities of the application at runtime can be challenging. While frameworks such as AngularJS and React are ideal for building web and in some cases native applications, providing users with the capabilities to extend those applications at runtime (with capabilities such as interoperable stand-alone applications, plug-ins, modules, applets, or widgets ‘programmed’ by third parties or end users) often introduces substantial security risks that need to be managed and mitigated.
Over the last two decades, we’ve had to implement and deploy several solutions where we needed to allow users (of various expertise) to extend our applications. The form and model for such extensions can take many shapes. In almost all cases, we ended up using some variation of an XML or JSON block (often with some type of a progamming UI) to describe the plugin (a plugin being: (a) some in-place user-interface component, (b) some logic/workflow/decision component, and (c) an ability to access and/or modify the core application data. For security reasons, we had to substantially limit what we allow the user to do – specially on the logic/workflow and data access components. For a class of trusted users, we would allow them to include some logic (programmable) elements (such as Javascript or AngularJS expressions) but that introduced substantial security concerns and operational complexities that we needed to mitigate.
What we needed is a programmable “language” that can be used to build embeddedable components (plugins/widgets) that is sufficiently flexible to allow for logic/workflow/branching, UI integration, and access to the application data, and do it all in a highly sandboxed, secure, and controlled way.
F(x) is an application framework to enable such capabilities.