doix is a node.js based framework for building middleware: systems that process requests by executing business methods using pooled resources, in a manageable and observable way. Each request is handled by a one-off object called job which job.outcome () method implements the common workflow: from fetching request details to cleaning things up.

The workflow's main step is invoking a business method: one per job. All methods possibly called by a job belong to modules of the hosting application. The exact method to call is determined by applying the application's naming conventions to the request content.

Other than that, the job's lifecycle includes adjusting the request, validating / sanitating it, reporting the result obtained or the error caught, disposing all resources possibly used. As one Job class serves all kinds of requests, all these tasks are subject to per instance configuration: it's set up by each specific job source. The point here is to isolate routine work: the application developer mostly implements the pure business logic as modules code, all the rest being provided by the framework and its global configuration.

For instance, in doix, the whole data processing is transparently logged: each meaningful event related to a request is communicated to winston, tagged for later analysis. Related events have related tags (e. g. messages from jobs coming from the same source have IDs with a common prefix).

The job's time to live can be limited, and both ways. First, the maximum latency can be configured for any job source, to cause errors on expiration. On the other hand, the special source class, Queue, lets implement a sequential single threaded request processing with a controlled throughput.

Although doix is designed to work with HTTP as the prime source of incoming messages, its core is mostly abstract and protocol agnostic, but there is a series of specific companion modules, e. g. doix-http featuring the WebService class: a source of jobs bound to an HTTP listener.

Similarly, the base library contains no example of the aforementioned resource pools. They are basically supposed to be wrappers around database drivers, so, to avoid adding unnecessary dependencies, such pieces of code are maintained separately: for example, doix-db-postgresql.