Flamegraph tool for node.js


Coming soon…



ui overview

General Page Layout

generic page layout

Page Wireframes

history page capture page manage page help page


Backend Tech Stack

  • TypeScript
  • Node.js
  • Express.js
  • SQLite3
  • Jest

Frontend Tech Stack

  • TypeScript
  • React
  • React-Router
  • React-Bootstrap

High Level Diagram

infernode architecture diagram


  1. Clone this repository
  2. npm install in the repo directory
  3. npm run dev to run the server with on-save recompile/reload

Additional project scripts

All scripts are accessible via npm run <scriptname>.

  • clean: Remove all contents of the ./dist/ directory
  • copy-assets: Copy static assets from ./src/ to ./dist/
  • lint: Run linter (ESLint) against the relevant client and server source code
  • prebuild: Sequentially runs lint, clean, and copy-assets prior to all builds
  • tsc: Performs TypeScript transpilation for the server project
  • build: Performs npm run prebuild, npm run tsc, and npm run webpack sequentially, will halt if any prebuild steps have non-zero exit codes
  • test: Performs a fresh build and then executes all test suites
  • start: Starts the node server in production mode, access via http://localhost:3000
  • dev: Starts the node and webpack-dev-server servers in development mode, both dynamically recompiling/bundling/restarting on source code changes, access via http://localhost:8080

Express.js Global Error Handler

  • Invoked via next( errObject: InfernodeError ).
  • Takes an InfernodeError type object with the following mandatory properties:
    • message: string: A technical error message not necessarily intended for end users
  • The InfernodeError object can optionally include:
    • userMessage: string: A non-technical error message intended for (public) end users or API consumers
    • httpStatus: number: A more specific HTTP status code to use for the response
    • controller: string: The Express middleware controller/function/method/operation that caused the error
  • Logs the entire error object + the request method and path to the server’s console.
  • The response status will be set to 500 by default if an errObject.httpStatus code is not provided.
  • In development mode, entire error object, request method, and request path will be sent in the HTTP response body as JSON.
  • In production mode, only the errObject.userMessage will be sent in the HTTP response body as JSON.


Commit Messages

For working branch commits a single line message is sufficient

For PR commits please add a longer description of the changes

Please author single line commit messages and PR commit titles to:

  • Start with capital letter
  • Have no trailing punctuation
  • Use imperative and present tense
  • Describe the outcome, not the process
  • Be less than 50 characters in length

Pull Requests

  • Development should be performed on branches from dev and PR’d back to dev once complete,
  • Releases will be performed by PRing to main.
  • Pull Requests to dev and main are blocked on passing GHA checks. In order to ensure your PR will pass checks, make sure that:
    • All new dependencies have been included in package.json/package-lock.json
    • All tests are passing locally via npm test
    • All ESLint checks pass locally via npm run lint
    • A new build is successful locally via npm run build
    • The app is functional in production mode via npm run build && npm start and browsing to http://localhost:3000

Please consider the following when filing pull requests:

  • Update working branch from dev
  • Test the above GHA check criteria locally
  • PR title should take the form of a commit message title
  • Body of PR should take the form of a full commit message body
  • Once approved, the PR author is responsible for squash merging into the destination branch
  • Branches should be deleted after merge

Branch Names

  • Use a new branch for each new feature and eventual PR
  • Use the format of “type/descriptive-outcome”
  • Types include:
    • bugfix
    • feature
    • docs
    • testing
    • refactor
  • The descriptive-outcome should describe what will be achieved by merging the branch


View Github