hipages / inceptum Goto Github PK

We want to talk to the outside world without dying if they do

Depends on #6
Instrument the mysql client so that we get per pool:

• Connection pool stats: established, active, idle, max size
• Connection borrowing stats: histogram of for how long we borrow connections from the pool
• Query execution time: histogram of execution time
• Slow queries: log any query that takes longer than a configurable number of millis (allow for Env override)

I tried to use jest for testing and it makes the build fail because of conflicting global types.

node_modules/@types/mocha/index.d.ts:66:18 - error TS2300: Duplicate identifier 'afterEach'.

66 declare function afterEach(description: string, callback: (this: Mocha.IBeforeAndAfterContext, done: MochaDone) => any): void;
                    ~~~~~~~~~

  node_modules/@types/jest/index.d.ts:31:13
    31 declare var afterEach: jest.Lifecycle;
                   ~~~~~~~~~
    'afterEach' was also declared here.

The solution would be to make @types/mocha a peer dependency, rather than adding it directly.

So that the MySQL client is "free standing" and can be used in or out of the IoC and without external dependencies

We want swagger to own the routing, but we don't want it to take over the platform.

Build a "simple" middleware for express that uses the Swagger file to manage:

• Request routing
• Validation of the request against the schema
• Validation of the response against the schema

Instrument with metrics:

• General count of response codes
• Counts of response codes per path
• Response time per path
• Slow requests log: Log any request that takes longer than a specified millis to fulfil (this should be overridable by path)
• Counter of errors by error class

The config dependency can be updated to v1.28 or later to make the configuration management more flexible.

Now that we are building on circleci, I think we should be moving this to circleci

Should we use HAL? or is Swagger enough?
What autodiscovery capabilities do we want

• How to do routing
• using Redux on both sides
• CSRF
• Authentication in general
• Caching

Calling addDirectory on a new InceptumApp will add all files in the directory in a recursive manner. However, there can be instances where a user wants to ignore some files or subdirectories in a given path.

For instance, if we write tests alongside the source files, with a .test.js/.spec.js prefix OR if we use a test directory as __test__ /test, inceptum will try to add these files to the app.

On the other hand, inceptum app will crash, if test specific configurations are there in the test files. (configs or globals which will be loaded by a test runner)

Thus there should be an options to Ignore sub-directories/files from the addDirectory method.

The logging framework uses Redis. It currently uses a "list", but also has the option of using a redis channel instead.
Figure out which one is better and if it's channel do the change and test.

Create utility classes we can use to push metrics (counters, gauges, histograms, etc) to a system that collects the stats.
We want to go with Promoetheus, se we should use the datadog protocol (extension of statsd protocol)

Currently the IoC framework supports singletons (which is what you normally need). But being able to register factories would be good.
A factory is an object definition that returns a new instance every time its getInstance method is called.

Symfony: http://symfony.com/doc/current/service_container/factories.html

I've settled on using bunyan as the logging framework as it allows for easier publishing of structure data (in principle).
One thing we need to test is whether the module that publishes logs to redis that is included with bunyan is compatible with the redis plugin of logstash to extract logs and push to ELK.

If this works, the next step will be to create a wrapper around the bunyan config to make it easier to manage.

We want our microservices to be able to talk with other microservices that follow our standards in an easy way.
It should use whatever auto-discovery capabilities we decide upon (reading the swagger of the service, or using HAL, etc)
The client should have a high-level API that resembles a RPC and not a low-level Rest-like API

It should be built on top of a circuit-breaker capable http client