| 1 | # What is Axiom?
|
| 2 |
|
| 3 | Axiom is a tool for standardizing the technology decisions of your organization, in a decoupled, modular way. This lets you focus on the development of features, while using standards for file location, project deploys, asset pipelines, etc.
|
| 4 |
|
| 5 | This is a role typically assumed by Frameworks. The goal of Axiom though is to be more of a 'framework toolkit', where you still have the freedom to swap out technologies, and leave out things you don't want.
|
| 6 |
|
| 7 | Features of Axiom include:
|
| 8 |
|
| 9 | * workflow standardization
|
| 10 | * an extensible application kernel
|
| 11 |
|
| 12 | The Axiom infrastructure is separated into four layers:
|
| 13 |
|
| 14 | * Runtime
|
| 15 | * Protocol
|
| 16 | * Plugins
|
| 17 |
|
| 18 | In addition, your application can be separated into:
|
| 19 |
|
| 20 | * Application Configs
|
| 21 | * Application Code
|
| 22 |
|
| 23 | # Runtime
|
| 24 |
|
| 25 | The Runtime is responsible for directing control flow. It interprets the Protocol as a configuration. Based on the Protocol, it calls Plugins/Services at the appropriate locations, at times when it deems appropriate.
|
| 26 |
|
| 27 | Because the Plugins are constrained to a Protocol, and not to a specific Runtime implementation, it is our hope that the Runtime layer can continue to evolve without disrupting the Plugin ecosystem.
|
| 28 |
|
| 29 | # Protocol
|
| 30 |
|
| 31 | The Protocol layer contains a group of Interfaces, each of which describes the lifecycles of workflows and runtimes for the application. The Interfaces are JSON-like configuration files - they may be in memory data structures with require statements or other inderections, but the resulting data structure should be pure data and should not contain any functions.
|
| 32 |
|
| 33 | Protocols must be given a name and version, and a definitive set of Interfaces. This allows Plugins and Runtime modules to identify themselves as being compatible with a given Protocol. The Protocol system allows for many 'Frameworks' to exist within the Axiom ecosystem, ideally leading to a more consistent experience for both application developers and framework developers.
|
| 34 |
|
| 35 | # Plugins
|
| 36 |
|
| 37 | The Plugins bring technologies from the Node.js ecosystem into the Axiom ecosystem. They are the bridge between general technologies and how those technologies should plug into specific workflows and runtimes. A given Plugin can extend many different Interfaces - for instance, installing the Mongoose Plugin you should expect that it
|
| 38 |
|
| 39 | # Design Decisions
|
| 40 |
|
| 41 | Within Axiom, we have selected Decoupled Architecture in place of Generated Boilerplate. This is not an exclusive decision. Our preference towards an architectural approach comes from the belief that this will lead to more inclusive systems which embrace and make use of the myriad of technologies currently available.
|
| 42 |
|
| 43 | # Implementation Decisions
|
| 44 |
|
| 45 | The core of Axiom's interworkings are implemented as communications on a message bus - Postal.js.
|