Interface Settings

default

false

default

3001

A Space is really just a Socket.IO.Namespace that Client-Browsers and instances of dffrnt.api can connect to. Depending on the implementation of dffrnt.api, certain Spaces will be required to connect to another auth/rest Space -- even if all of said Spaces are within the same instance:

Instance	Requirement
auth only	Needs a remote connection to it's internal Namespace.
rest only	Needs a remote connection to an auth-Space (if using authentication).
page only	Needs a remote connection to a rest-Space (unless page data is all static).
auth+rest	Needs a remote connection to a auth-Space.
rest+page	Needs a remote connection to a rest-Space.
auth+rest+page	Needs a remote connection to an auth-Space and a rest-Space.

If this property is not set, the system will assume ${protocol}://localhost/gbl-${spaceName}, where ${spaceName} is the name provided for any given auth/rest Space in {@link CFGSpace.config}.

These can refer to Spaces that are internal, as well as external to this particular web-server. This can be useful when there becomes a need to "break up" the functionality into separate web-server. Take this project structure, for example:

[Your-Machine]
   ├── dffrnt.api-auth/ >> This web-server will handle the Authentication @ https://localhost:7443/gbl-auth
   ├── dffrnt.api-rest/ >> This web-server will handle the Data Requests  @ https://localhost:8443/gbl-rest
   └── dffrnt.api-view/ >> This web-server is the Web-App for the Clients @ https://mysite.com

The settings for each instance would be configured as follows:

// [Your-Machine]/dffrnt.api-auth/config/settings.cfg.js
module.exports = {
    // Needs a remote connection to it's internal Namespace.
    Services: ["https://localhost:7443/gbl-auth"]
};
// [Your-Machine]/dffrnt.api-auth/config/settings.cfg.js
module.exports = {
    // Needs a remote connection the auth-Space.
    Services: ["https://localhost:7443/gbl-auth"]
};
// [Your-Machine]/dffrnt.api-auth/config/settings.cfg.js
module.exports = {
    // Needs a remote connection to the auth-Space, and the rest-Space.
    Services: ["https://localhost:7443/gbl-auth","https://localhost:8443/gbl-rest"]
};

In the scenario above, you have a single-machine running 3-instances of dffrnt.api. Each are configured accordingly to handle their specified tasks.

But what if you wanted to take the separation even further? Like using separate machines for each instance? For example

[Machine-1]
   ├── dffrnt.api-auth/ >> This machine will handle the Authentication @ Port 443 (https://auth.mysite.com)
[Machine-3]
   ├── dffrnt.api-rest/ >> This machine will handle the Data Requests @ Port 443 (https://rest.mysite.com)
[Machine-3]
   └── dffrnt.api-view/ >> This machine will is the actual WebApp @ Port 443 (https://mysite.com)

The settings for each would be configured as follows:

// [Machine-1]/dffrnt.api-auth/config/settings.cfg.js
module.exports = {
    // Needs a remote connection to it's internal Namespace.
    Services: ["https://auth.mysite.com"]
};
// [Machine-2]/dffrnt.api-auth/config/settings.cfg.js
module.exports = {
    // Needs a remote connection the auth-Space.
    Services: ["https://auth.mysite.com"]
};
// [Machine-3]/dffrnt.api-auth/config/settings.cfg.js
module.exports = {
    // Needs a remote connection to the auth-Space, and the rest-Space.
    Services: ["https://auth.mysite.com","https://rest.mysite.com"]
};

You could take it even further, setting up multiple instances of each implementation, every one of them on their own machine, use NGinX (or something) to load-balance each Service and these config-settings would still apply. Unfortunately, I don't have the time or patience to write up that example.

Once the application-server is up and running, the JSON document can be found at /apidocs.

This is shot-for-shot the same info, externalDocs, and servers object described in the OpenAPI 3.0 spec (execpt for the openapi version), so check that out to get an idea of what goes where. Any other objects are defined... _automagically (LOL).

Example

{
    info: {
        title: "My API",
        description: "It's an API Doc.",
        termsOfService: "https://www.mysite/terms",
        contact: {
            name: "My Site Support",
            email: "custome.support@mysite.com",
            url: "https://www.mysite/support",
        },
        version: "2.1.8"
    },
}

The dffrnt.api framework automatically installs and uses two predefined -- and reserved -- STTG.Folders, Publics & Uploads. These folder configurations are required internally, but can be altered by redifining them here; however, doing so -- particularily, with Publics -- could potentially introduce problems. That said, do it at your own risk, and only if you know what you're doing.