Open Sourcing con’t – Repos and Modules

Our work progresses on open sourcing the project. By now, we have much more direction.

We’ve settled on splitting our code up into modules. These are individual GitHub repos (public, open source) that form the tiny parts of our framework. They’ve also been renamed to better reflect their purposes now that the project is coming together:

As you may notice from visiting those repos, the technology used to implement the module is appended to the end of the repo name and “rutilus”, the name of the whole framework, is prepended. For example, “rutilus-logger-node” describes the logger module implemented in Node.js. The technology being appended means individual repos can be created by the open source community as more technologies become attractive to the framework. We might eventually see, for example, a “rutilus-logger-go” module, if GO web frameworks become the best-performing and the best for the Rutilus framework.

Each of these repo names is used for the NPM modules as well, NPM being the “node package manager”, from which developers will pull modules to create their own apps. This is the same place we get libraries such as those that provide the HTTP and WebSockets functionality we use in our modules.

We ended up being able to satisfy the other end of the spectrum as well, in terms of making our framework both customizable and easy to use because we also have the rutilus-nodejs-aws repo and NPM module. It contains pre-configured settings for using the above mentioned individual modules in an app that is intended to use Node.js technology and be hosted in a Docker container environment on AWS. This parallels our setup that we created for Engineering.com.

Developers who intend to use the system like we designed, and who value a “set it and forget it” type system can opt to use the nodejs-aws repo. Developers who value more control and who want to swap some modules out for future new modules (that use different technologies), or who simply value more fine grained control over configuration or hosting environments, can opt to use the individual modules. They would be responsible for glueing them together and getting their system hosted themselves.

In any case, we may even be able to make configuration simple for anyone who uses this, even those who use the individual modules. Every module’s configuration is related to the others. For example, the Logger must log certain information, and the Observer must listen to user events for that certain information. Why have two separate configurations to do in each module? We’re investigating coming up with a common format for configuration of the data to collect, which would be hosted “above” (see the diagram below for a visualization) the individual modules, and passed down into the individual modules as the entire system is compiled (in the case of the Observer) and ran (in the case of the Logger).

new_config

An example common config file might look like:

hooks: {
  // pre-made hooks to be disabled.
  skipped: [
    'job',
    'industry',
  ],
  // custom, user-defined hooks to be enabled
  added: {
    // grab the contents of an element
    info: [
      // matches CSS class name "rutilus-favorite-color"
      'favorite-color',
    ],
    // actions performed on specific elements to track
    action: [
      {
        type: 'LEFT_CLICK',
        // matches CSS class name "rutilus-poll"
        target: 'poll',
      }
    ],
  },
},
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s