Corredor Server

Corredor server is mainly responsible for:

Loading, processing and serving automation scripts,
server-script execution.

Server-scripts file structure

/server-scripts (1)
    /... (2)

1	Root folder for all server scripts (under each search path).
2	Undefined file structure; can be defined as needed.

Client-scripts file structure

/client-scripts (1)
    /auth (2)
        /... (7)

    /admin (3)
        /... (7)

    /compose (4)
        /... (7)

    /messaging (5)
        /... (7)

    /shared (6)
        /... (7)

1	Root folder for all client scripts (under each search path).
2	Defines a bundle for Corteza Auth.
3	Defines a bundle for Corteza Admin.
4	Defines a bundle for Corteza Low Code.
5	Defines a bundle for Corteza Messaging.
6	Reserved directory for any shared logic, such as custom libraries, assets, …
7	Undefined file structure; can be defined as needed.

Automation script processing

Flow outline:

Scan extensions defined in the .env: Go over all extensions defined in the CORREDOR_EXT_SEARCH_PATHS .env variable. Extensions are separated by :.

Note that all of the following steps are performed for each of the extensions.

Dependency management: Load all requested dependencies by the given extension.

Dependencies are scoped to the extension that has requested them. If two extensions wish to use the same dependency (axios for example) they both should define it.

Parse server-scripts: Go over each script file defined inside the server-scripts sub-tree. Parse the script and extract all the important bits such as dependencies, triggers, iterators and the exec function itself.

At the moment server scripts are not bundled.

Parse client-scripts: Go over each script file defined inside the client-scripts sub-tree. Parse the script and extract all the important bits such as dependencies, triggers, iterators and the exec function itself. Create a per-app bundle containing relevant automation scripts, dependencies and other relevant bits. Refer to Client-script bundling for details about creating bundles.

Bundling is done using webpack.

Prepare a list of available scripts: This allows us to inspect what scripts were loaded from inside web-apps. It also simplifies the process of determining available automation scripts from inside client-script bundles.

Failing automation scripts are also included in this list but provide a descriptive error. This allows easier debugging.

Automation script naming

Corredor determines automation scripts name on-the-fly from the extension and it’s relative path. This simplifies the script’s definition as we don’t need to worry about unique names and possible conflicts between extensions. Script name is defined as:

/${path to script}/${file name}:${export name}(1)(2)(3)

1	Path to the script file, excluding the search path.
2	The script’s file name.
3	Used export name; this will normally be `default`.

The base search path of the extension is excluded from the script’s name. This allows easier reusability across different systems that don’t define the same file hierarchy.

Client-script bundling

Client-scripts are bundled using webpack. Bundles help us assure consistent code execution between different user-agents and allow the use of external node dependencies.

The bundling process creates multiple bundles, one for each available application (Auth, Admin, Low Code, …). This simplifies the process of registering client-scripts on the client-side.

Bundle name is determined from the extensions file-structure:

<search-path>/client-scripts/<bundle>/<path-to-script>/*.js

The bundling process creates a boot loader file for each available application. The file consists of { name, triggers, security } JSON objects for each available automation script. The Webpack is then executed over each boot loader file to create a bundle for the given application. If the application doesn’t define any automation scripts the bundling process is omitted.

gRPC server

Corredor server allows communication via the gRPC server via the gRPC protocol via the following services:

Server scripts with list and exec procedures,
client scripts with list and bundle procedures.

Refer to protobuf service definition for the details on the definitions.

You can use BloomRPC or similar when working solely on the Corredor server to remove the need for the Corteza server.

Server-script execution

Corredor server is and should not be able to perform any code execution on its own. Any execution is and should be invoked either by the Corteza server or manually via gRPC protocol.

Watching for changes

When the Corredor server is running in development mode or is configured so via the .env variables it uses file watchers to detect changes to the extensions and dependency definition files. When a change occurs, the server wil restart the entire Automation script processing flow.