Sign Up for Free

RunKit +

Try any Node.js package right in your browser

This is a playground to test code. It runs a full Node.js environment and already has all of npm’s 1,000,000+ packages pre-installed, including trails-service with all npm packages installed. Try it out:

var trailsService = require("trails-service")

This service is provided by RunKit and is not affiliated with npm, Inc or the package authors.

trails-service v2.0.0

Trails Service Class


Gitter NPM version Build status Dependency Status Code Climate Follow @trailsjs on Twitter

Note: This module is deprecated in Trails v2. It will be merged into trailsjs/trails in v3.

Trails Service Class. Exposes Trails Application resources to the class instances. Services should extend this Class. This module is installed by default in new Trails applications.


const Service = require('trails-service')

class MyService extends Service {
  serviceMethod () {'hello')
    // ...


Important Note

The specification below is not yet implemented in Trails 1.0. Implementation is tentatively scheduled for 2.x series release.


In Trails, Controller methods should remain lightweight. Their primary function is to extract the necessary data from the request, and pass the data into a Service method to perform any necessary work. Controller methods also handle any errors received from the Services, and translate them for the client response.

The work performed by the Services can vary, and depending on the kinds of tasks performed by the Service methods, the following patterns can be used to optimize and scale your application.

Traditional Single-Process


By default, Services are instantiated in the same process as the Trails Application. Controllers invoke Service methods directly. The Service Interface directly passes through method calls and arguments to the Service Layer. The scalability of the Service Layer and the Application Layer are coupled together, one-to-one.

For example, Sails Services use this Traditional Single-Process pattern.



This pattern is applicable for web applications under low/normal load, where the service methods mainly are performing async I/O, such as performing database queries. Should not be used for memory-bound tasks or CPU-intensive tasks such as video encoding, PDF generation, etc.



Within a single machine or server, multiple Service processes are spawned from the main Application. The Service Interface invokes the Service methods via IPC (Inter-process Communication). The Service Layer returns the response also via IPC, and the Service Interface resolves the caller's Promise.



Use this pattern to offload CPU-bound work from the main process. Useful for Services that perform short-lived but CPU-intensive tasks such as cryptographically-strong random number generation, or data transformations on small/medium-sized datasets. Should not be used for memory-bound tasks.

Multi-Node Worker Queue






RunKit is a free, in-browser JavaScript dev environment for prototyping Node.js code, with every npm package installed. Sign up to share your code.
Sign Up for Free