Profound API runs on the Profound.js runtime, so the two products share a single instance configuration file and the same set of configuration properties. Most of the topics below are common to both products and are documented once in the Profound.js section of this space; the links in the table open those shared reference pages.

Overview

Every Profound API instance is configured through a single file named config.js, located in the installation directory of the instance. This page indexes the configuration topics and describes what each one covers, so you can go straight to the one that applies to your environment.

If you are setting up a new instance, start with the example below to understand the structure of config.js, then define your data sources with Database Connections. The remaining topics are optional and apply only to specific use cases.

Configuration Topics

Topic	What It Covers	Use It When

Topic	What It Covers	Use It When
Configuration File Details	The structure of `config.js` and a complete index of every available configuration property.	Always - this is the starting point for any instance, and the reference for every individual setting.
Database Connections	The `databaseConnections` option: defining one or more named connections to Db2 for i and external databases, and reaching them from your code with `pjs.getDB()`.	Almost always - any API that reads or writes data needs at least one connection. Required if you connect to more than one database.
HTTPS/SSL	The `sslKey`, `sslCert`, `securePort` and `redirectHTTP` options, with worked examples for HTTPS only, HTTP and HTTPS together, and redirecting all HTTP traffic to HTTPS.	You are exposing APIs outside a trusted internal network, or a consumer requires an encrypted connection.
Multiple Instances	Running separate instances side by side on one IBM i, each in its own directory with its own port and connector library, and the environment variables that direct a Genie session to a particular instance.	You need isolated Production, QA and Development environments on the same partition.
Clustering	Using the Node.js cluster module to spawn worker processes across multiple CPU cores behind a shared port, configured through a `cluster.json` file.	A single CPU core is your bottleneck. Check this first: the API Dashboard is not compatible with a clustered instance and will report incomplete statistics. Tune connection pool sizes before clustering, and consider a load balancer instead if you need to scale across servers.
Using Git to Manage Modules on IBM i	Two approaches to source control for your modules: a repository created directly over the modules folder on the IBM i, or a remote repository where developers work locally and changes are pulled down to the IBM i.	More than one developer maintains your API code, or you need version history and a rollback path.
Server Performance	The `--optimize` start-up argument, which caches parts of your application so it runs faster, and how to apply it on IBM i and on other platforms.	A production instance where the code is stable. Not for development - it disables hot module reloading, and changes to screens, modules and database tables all require a restart.
Performance Logging	Adding `plog=1` to a request URL to log timings for the individual steps of a call, including JS modules, ILE programs and service program procedures.	An API is slower than expected and you need to identify which step is responsible.

Example: Standard `config.js` File

The example below is a complete, working configuration for a single Profound API instance that serves APIs from the pjssamples path and reads from Db2 for i. Use it as a starting point and change the values to match your environment.

The instance must already be installed, and any library or directory named in pathlist must exist on the server.

module.exports = {
  // The port this instance listens on. Give every instance on the
  // same server its own port.
  "port": 8081,
  // URL prefix for every Profound API route. When omitted, the prefix
  // defaults to "/wsapi". With the value below, an API is reached at:
  //   http://your-server:8081/apis/...
  // The value "/api" is reserved and cannot be used.
  "apiPrefix": "/apis",
  // Directories and IBM i libraries searched for modules and API files.
  // Required - the instance will not start without it.
  "pathlist": [
    "pjssamples"
  ],
  // Maps URL aliases to module files. Also required for a standard
  // instance, even one that only serves APIs.
  "initialModules": {
    "/hello": "pjssamples/hello",
    "/connect4": "pjssamples/connect4"
  },
  // Location of the Profound UI static files (htdocs): images, CSS and
  // client-side JavaScript. May be an absolute path, a path relative to
  // the installation directory (as below), or a URL.
  "staticFilesDirectory": "htdocs",
  // Database connections your APIs use through the pjs.getDB() API.
  // The "IBMi" driver is the native Db2 for i connection.
  "databaseConnections": [
    {
      "name": "default",
      "default": true,
      "driver": "IBMi"
    }
  ],
  // Session inactivity timeout, in seconds. 3600 = one hour.
  "timeout": 3600
}

Each property within the JSON object represents a Profound API setting.

Configuration

Overview

Configuration Topics

Example: Standard config.js File

Related Pages

Example: Standard `config.js` File