Seneca Gateway is a plugin for Seneca

Handle incoming messages within other frameworks.

@seneca/gateway

| | This open source module is sponsored and supported by Voxgig. | | ---------------------------------------------------- | --------------------------------------------------------------------------------------- |

Introduction

seneca-flame is a seneca plugin created to be a debug tool for seneca. When using seneca-flame, the plugin starts to capture metadata that is generated by seneca, and starts to aggregate it in a flame. seneca-flame has a deep and useful integration with seneca-debug

Install

npm install @seneca/flame

Usage

First of all, you need to install the plugin and then 'boot' it in the seneca instance: seneca.use('flame', { capture: true }) From now on, seneca-flame will start to capture and aggregate data automatically. seneca-flame also provides some useful commands:

• sys:flame,capture:boolean Will start/stop capturing data
• sys:flame,cmd:get,cached:boolean Will return the current flame data. The cached option can be used to compare if the previous call has the same value of the current one, if that's true, the command will reply with { data: false }
• sys:flame,cmd:snapshot,format:string This command will generate a file with the current flame data, the format parameter can be html or json

More Examples

Debug flow

When debugging something, you can quick add seneca-flame into your plugins, start capturing data with sys:flame,capture:true, proceed the actions you need to debug, then you can pause the capture with sys:flame,capture:false, and also generate an .html file to visualize the flamegraph with sys:flame,cmd:snapshot,format:string

Motivation

The motivation behind this is to improve our seneca debug tools and have a tool where we can collect trace data in an structured way.

Support

API

Data structure and algorithm

The flame data structure is created using a tree algorithm, where the first (root) layer is inserted by default, the second layer of trees are always the name of the plugins, and the third and subsequential layers are the children actions of each of those plugins. Each node of the tree have those values:

• name: The name of the action or plugin
• value: The mean of time an action took
• children: A list of children to this plugin/action
• _inner: A set of metadata's of the node.

Contributing

Background