Issue Discussion

Fabrix will attempt to merge an array into it's tuple schema, eg.

main.spools: [
  Spool1,
  Spool2,
  Spool3
]

Becomes:

main.spools.0.Spool1,
main.spools.1.Spool2,
main.spools.2.Spool3

This is very problematic as unsetting or overriding arrays in the config becomes very unpredictable, especially as they are chained and modified by outside spools.
Instead config arrays should be converted to key values where ever possible. eg.

main.spools: {
  spool1: Spool1,
  spool2: Spool2,
  spool3: Spool3,
}

The above is now easily predictable.
This would require a breaking change, so realistically this should go on the v2 branch.

lifecycle

Currently, each spool contains a spool.ts file that sets up it’s lifecycle. There is no way to override this if imported and that has always bothered me.
There’s got to be a good way to allow configuration of a lifecycle from the root app as an override. The configuration merging is done before the lifecycle starts anyways.

fabrix has a root configuration proxy where it stores and retrieves its famous tuples. Fabrix is also an event emitter. It should:

• should emit when config is updated using .set after all the map merging is done.

This will allow for the cluster module to notify workers when a change has happened in the config via messaging!

Attached is a possible script implementation to check if a spool is actually a class. This helps pure JS users more than TS users, but, since it all runs in JavaScript at the end of the day, it makes sense to do an explicit check.

export default fn => {
  if (typeof fn != "function") {
    return false
  }

  let proxy = new Proxy(fn, {
    construct: () => fn,
  })

  try {
    new proxy
  } catch {
    return false
  }

  return true
}

Additionally, with babel constructing things down to es5 for browsers, it would be helpful to detect if the spool is es5 or es6 already.

There is a spool called "boostrap" that simply listens for when an app starts and then performs some logic. It makes sense to add a "ready" method to spools that can be run when fabrix emits fabrix:ready

Issue Description

When console.log(this.app) the Logger Proxy creates a stack issue and fails.

Environment

• node version: 10.0
• fabrix version: > 1.1.3
• operating system: OSX, Linux

Issue Description

Config merge of function over function returns object

Environment

• node version: 10.0.0
• fabrix version: 1.5.2
• operating system: macOS, Linux

Issue Description

At this point, TypeScript 3.0 has mainstream adoption, should the upgrade wait until v2 or a v1.7 release?

Issue Description

When using the CLI, the fabrix archetype is used, there should be a test for the archetype that should be run with normal PRs and Merges

Environment

• node version: 10.0.0
• fabrix version: 1.5.8
• operating system: macOS, Linux

Issue Description

when a config variable is 'undefined', it will create an object by default when merged ontop of an existing undefined

Environment

• node version: 10.0.0
• fabrix version: 1.1.4
• operating system: MacOS, Linux

Issue Description

Add strong types to Fabrix.

Environment

• node version: ???
• fabrix version: ???
• operating system: ???

Issue Description

Lifecycle listeners should throw a warning if the lifecycle event will not exist.

Environment

• node version: 10.0.0
• fabrix version: > 1.1.4
• operating system: macOS, Linux

Languages like Erlang/Elixir are super solid because of the way they use mailboxes (among other things). Fabrix is already just extending the base "Emitter" class to give it most of its functionality. There's something to be said about giving each spool and each thread/spool it's own mailbox and in turn it's own address for the spool and the threads that it's using. This will helps fabrix distribute better and opens opportunity for a new class of spools, ones that allow connections between different instances of the core.

Example:

<App Address:uuid> -> <Spool Address:uuid> -> <Method Thread Address:uuid>
<App Address:uuid> -> <Spool Address:uuid> -> <Method Thread Address:uuid>
<App Address:uuid> -> <Spool Address:uuid> -> <Method Thread Address:uuid>

doing app.spools or app.models could resolve where those things actually live and mailbox the requests etc,

Many of these types of small enhancements came up while constructing spool-broadcast, and honestly, it makes sense for a fabrix app to not have to reside on a single machine as a micro service, when it's already so close to being distributed with some slight but significant enhancements.

Using proxies, generators, and async/await, we could also keep everything compatible with the existing ecosystem, but also get the huge benefit of fully distributed applications (that still have perks like using other frameworks inside fabrix).

This could be a v2.0 or a v1.7 feature.

Issue Description

When creating a new fabrix app using the [email protected]. and set up a Controller

export class TestController extends Controller {
  hello (request, reply) {
    return '<h1>Hello Fabrix</h1>'
  }
}

export const routes = {
  'hello': {
    'GET': {
      handler: 'TestController.hello'
    }
  }
}

I get the following error on npm start:

(node:24308) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 2): AssertionError [ERR_ASSERTION]: Missing or undefined handler: GET /hello

Environment

• node version: v8.9.4
• fabrix version: 1.5.8
• operating system: Windows 10 Enterprise

Hi.. Is this project still active ? Would it be safe for me to create a new project and learn this frame work or is Fabrix slowly dying?
Sorry for creating an issue, but the Gitter link was giving an 404 (https://gitter.im/fabrix-app/fabrix).