Helion Energy is building a new facility in the state of Washington.
Injecting schemas
Internally Airport uses "on the stack", token based dependency injection
to allow for seamless framework upgrades on each device. However this
type of injection is non-standard and can throw schema developers off
(as something unfamiliar and therefore unnatural). With introduction of
isolates adding more tranditional constructor based dependency injection
scheme becomes possible.
Enter the typeless, on the stack dependency injection. Unlike constructor based injection it allows to keep the non-upgraded classes the same after the upgrade, with only the upgraded classes being reloaded in the VM. This is combined with "request caching" during the upgrade process, which creates a small time-window during which no active requests are going though the system. Together they allow Airport to catch all incoming requests and delay their execution while a fast upgrade is happening (a few classes being quickly replaced on the fly) and then continue with serving those same requests as if nothing has happened. All while the user if completely oblivious to the fact that a bug has just been fixed.
This makes for a much smoother user experience, which could make or break Airport at the beginning, right when it will have to be patched frequently. The user will be able to access the ungrade log, in case they are curious or concerned with code being upgraded without their knowledge. Eventually a setting can be added that will prompt the user for upgrades. But this also makes for a more clunky developer experience. Every method that uses other injectable objects now has to inject them explicitly (or have them passed in via the execution context). Also the injection will feel unnatural to the fast majority of developers because it uses tokens.
The cool thing about isloate sandboxes is that upgrading them can be done wholesale, or at least the 3rd party schema code, which will be deployed via a separate bundle. Under the covers (in DAO superclasses) it will use Airport IOC tokens to access the rest of the framework. All of the requests coming to a schema isolate and to the core framework from the schema isolate can be cached while the 3rd party bundle is loaded. To make it all work, all API endpoint classes will also have Airport IOC tokens (not exposed to the developer) so that they can be (re)loaded at run time.
Why "on the stack"?
Airport has it's own unique dependency injection system. It's adoption was driven by the fact that Airport will run in non-controlled environments - end user devices. On top of that it can have any number of Apps access it (locally) at any given point in time (either via user interaction or in the background). In such environments performing framework upgrades becomes tricky - App's CRUD calls will not work while the upgrade is happenning. And depending now how the apps are written this can (and most probably will) lead to broken user experiences. Being an upcoming framework Airport can risk being deleted from User's devices if they are frustrated by possibly frequent outages of service (realistically, the rate of bug fixes at the beginning will be high).Enter the typeless, on the stack dependency injection. Unlike constructor based injection it allows to keep the non-upgraded classes the same after the upgrade, with only the upgraded classes being reloaded in the VM. This is combined with "request caching" during the upgrade process, which creates a small time-window during which no active requests are going though the system. Together they allow Airport to catch all incoming requests and delay their execution while a fast upgrade is happening (a few classes being quickly replaced on the fly) and then continue with serving those same requests as if nothing has happened. All while the user if completely oblivious to the fact that a bug has just been fixed.
This makes for a much smoother user experience, which could make or break Airport at the beginning, right when it will have to be patched frequently. The user will be able to access the ungrade log, in case they are curious or concerned with code being upgraded without their knowledge. Eventually a setting can be added that will prompt the user for upgrades. But this also makes for a more clunky developer experience. Every method that uses other injectable objects now has to inject them explicitly (or have them passed in via the execution context). Also the injection will feel unnatural to the fast majority of developers because it uses tokens.
Isolate schemas are different
With the introduction of V8 isolates schema developers can now write code that will be executable in a sandbox environment. This will expose the "unnatural" nature of Airports current injection system and can become a barrier to developer adoption.The cool thing about isloate sandboxes is that upgrading them can be done wholesale, or at least the 3rd party schema code, which will be deployed via a separate bundle. Under the covers (in DAO superclasses) it will use Airport IOC tokens to access the rest of the framework. All of the requests coming to a schema isolate and to the core framework from the schema isolate can be cached while the 3rd party bundle is loaded. To make it all work, all API endpoint classes will also have Airport IOC tokens (not exposed to the developer) so that they can be (re)loaded at run time.