HTTP Transport layer that wraps over express@4.x and abstracts away any transport-related information.

Installation and usage
npm i --save thorin-transport-http@1.x
'use strict';
// app.js entry file
const thorin = require('thorin');

thorin.addTransport(require('thorin-transport-http'));   // <-- add this line => {});

# run once to allow the transport to set itself up
node app.js --setup=transport.http
Default configuration
  • debugtrue Enables or disables request debugging
  • port3000 Default port to bind the server
  • basePath/ Default base path to mount the root router
  • actionPath/dispatch Action path used to dispatch actions
  • authorization.headerAuthorization The HTTP Header to use as the source of an intent's authorization property, with the authorization type set to "TOKEN"
  • authorization.cookietpsIf set, the set cookie name will be the source of an intent's authorization property with the authorization type set to "COOKIE"
  • ip0.0.0.0 Default IP to bind the server to
  • corsfalse If set to true, add Access-Control-Allow-(Origin|Methods|Credentials|Headers) HTTP Headers to enable Cross-Origin Resource Sharing. You can also specify the array of domains that CORS will be enabled on
  • trustProxytrue Trust or not the X-Forwarded-For HTTP header.
  • staticthorin.root + '/public' The absolute path to the public directory containing static assets.
  • options.payloadLimit50000 The maximum size of any incoming request payload. If you're expecting large payloads, you should consider changing this to the appropriate value.
  • helmetobjecthelmet security HTTP header configuration.
The HTTP application comes with the default helmet configuration bellow. For a complete configuration view, visit the official docs.
   frameguard: false,
   xssFilter: {
      setOnOldIE: true
   contentSecurityPolicy: {
      browserSniff: true,
      disableAndroid: false,
      setAllHeaders: false
   dnsPrefetchControl: {
      allow: false
   hsts: false,
   ieNoOpen: true,
   noCache: false,
   hpkp: false
Making requests to your server

The easiest and fastest way to make requests to your server is by doing POST requests to your /dispatch endpoint. Since you define actions, you can call them (almost like a RPC) in a redux-friendly way.

curl -H "Content-Type: application/json" \
     -X POST \
     -d '{"type": "{yourActionName}", "payload": {"yourInput": "payload", "asAn": "object"}}' \
Extended Thorin.Action
If called, the action will only be processed via an alias, and it will not be processed by the action's name.
'use strict';
   .alias('GET', '/home')
   .aliasOnly();  // accessible only via GET /home, and not dispatch my.action
actionObj.enableCors(domain, opt)
Enables CORS on the current action when requested either via an alias or dispatch.
  • domainstringif specified, the origin domain that the CORS request will work with
  • opt.credentialsboolean if set true, adds the Access-Control-Allow-Credentials header
Transport functionality
Manually register an express middleware. Express middlewares are registered after CORS handlers and the static middleware.
  • fnfunction the express middleware function that will be called with fn(req, res, next)
Stops routing intents that come for the specified action, temporary disabling the action processing
  • namestring the action name
Re-enables routing to the given action.
  • namestring the action name
Override the default API intent response structure by registering a custom function to call when providing the JSON structure in an intent's response. This should only be used to provide backward compatibility in response structures.
  • fnfunction the callback function to use as
The callback will be called with the default fn(err, data). If err is set, the intent contained an error and you should generate your own error format. Otherwise, generate your result format from the data object.
trustProxy() : boolean
Returns whether or not the http server trusts the X-Forwarded-For header
app : ThorinExpressApp
Expose the internal thorin express app wrapper. This property should only be accessible by components that somehow require access to the internal app. Backward-compatibility is not guaranteed in this case.
Do you have a question or is something missing?

You can always create a new issue on GitHub or contact one of the core founders by chat.