The code editor is the main component for building scripts in getOperate’s script editor, but it is also used in getOperate’s Flow Editor to build steps or in the App Editor to add inline scripts.

​
Parameter Inference

getOperate ensures that the parameters passed to scripts, flows, and resources match the expected format and type. This mechanism relies heavily on JSON Schema, a standard used to define the structure and validation rules of JSON data. As you write your scripts or define flows and resource types in getOperate code editor, JSON Schema is used behind the scenes to construct a comprehensive specification of the expected input parameters. This specification not only defines the types of each parameter but also provides descriptions and sets out any constraints that might apply, such as which parameters are mandatory.

​
Add Resources and Variables to Code

You can directly access Variables and Resources from the Code Editor.

​
Resources

There are 2 main ways resources are used within scripts:

​
Passing resources as parameters to scripts (preferred)

Provided you have the right permissions and the resource type exists in the workspace, you can access resource types from scripts, flows and apps using the getOperate client or TypedDict in Python. From the code editor’s toolbar, click on the + Type button and pick the right resource type. For example, to access the u/user/my_postgresql resource of the posgtgresql Resource Type we would create a script: 
type Postgresql = object;
// OR one can fully type it
type Postgresql = {
    host: string;
    port: number;
    user: string;
    dbname: string;
    sslmode: string;
    password: string;
    root_certificate_pem: string;
};

export async function main(postgres: Postgresql) {
    // Use Resource...
}

​
Fetching them from within a script by using the getOperate client in the respective language

By clicking on + Resource, you’ll get to pick a resource from your workspace and be able to fetch it from within the script. Python: 
getOperate.get_resource("u/user/foo")
Type Script: 
getOperate.getResource('u/user/foo');
Go: 
getOperate.GetResource("u/user/foo")
Bash: 
curl -s -H "Authorization: Bearer $GOPRT_TOKEN" \
"$BASE_INTERNAL_URL/api/w/$GOPRT_WORKSPACE/resources/get/u/user/foo" \
| jq -r .value

​
Contextual variables

Contextual Variables are variables whose values are contextual to the Script execution. They are automatically set by getOperate. This is how the Deno and Python clients get their implicit credentials to interact with the platform. See the Contextual tab on the Variable page for the list of reserved variables and what they are used for. You can use them in a Script by clicking on “+Context Var”: Reserved variables are passed to the job as environment variables. For example, the ephemeral token is passed as GOPRT_TOKEN.

​
User-defined variables

There are 2 main ways variables are used within scripts:

​
Passing variables as parameters to scripts

Variables can be passed as parameters of the script, using the UI based variable picker. Underneath, the variable is passed as a string of the form: $var:<variable_path> and replaced by the worker at time of execution of the script by fetching the value with the job’s permissions. So the job will fail if the job’s permissions inherited from the caller do not allow access to the variable. This is the same mechanism used for resource, but they use $res: instead of $var:.

​
Fetching them from within a script by using the getOperate client in the respective language

By clicking on + Variable, you’ll get to pick a variable from your workspace and be able to fetch it from within the script. Python: 
getOperate.get_variable("u/user/foo")
Type Script: 
getOperate.getVariable('u/user/foo');
Go: 
getOperate.GetVariable("u/user/foo")
Bash: 
curl -s -H "Authorization: Bearer $WM_TOKEN" \
"$BASE_INTERNAL_URL/api/w/$WM_WORKSPACE/variables/get/u/user/foo" \
| jq -r .value
The last example is in bash and showcase well how it works under the hood: It fetches the secret from the API using the job’s permissions through the ephemeral token passed as environment variable to the job.

​
Code Assistants

getOperate integrates code assistants into its code editor to provide language-specific suggestions, linting, formatting, and more.

​
How Code Assistants Work

The code assistants in getOperate are integrated into the Monaco code editor. getOperate leverages servers in the backend to perform calculations and provide assistance to developers. The communication between the code editor and the backend servers is established using the Language Server Protocol (LSP). Here’s an overview of how the code assistants work:
  1. Language Server Protocol (LSP): getOperate utilizes the Language Server Protocol, a standardized protocol for communication between code editors and language servers.
  2. Language Servers: For each supported programming language, getOperate employs dedicated language servers responsible for providing code assistance and language-specific functionality. The following language servers are used by getOperate for each language:
    • Deno: Deno LSP
    • Python: Ruff, Black, Pyright
    • Bash: shellcheck
    • Go: Go LSP
  3. WebSocket Communication: The language servers communicate with the getOperate backend through websockets, enabling real-time exchange of information between the code editor and the language servers.
  4. Calculations and Suggestions: As developers write code in the getOperate editor, the language servers process the code, perform calculations, and provide relevant suggestions. These suggestions can include auto-completion, syntax highlighting, linting errors, formatting options, and more.
By integrating these code assistants, getOperate enhances the development workflow, enabling developers to write code more efficiently, identify and correct errors, and adhere to best practices specific to each programming language.