Applications overview¶

A Nextmv application is an entity that contains a decision model as executable code. An application can make a run by taking an input, executing the decision model, and producing an output. An application is defined by its code, and a configuration file named app.yaml, known as the "app manifest".

Think of the app as a shell, or workspace, that contains your decision model code, and provides the necessary structure to run it.

There are two types of applications: custom and subscription. Subscription apps and custom apps mainly differ in how the code is accessed and versioned:

• with custom apps you control the code for your model and how versions of this model are published;
• with subscription apps, you are subscribed to a custom app in the Nextmv Marketplace and someone else controls this model code and the published versions.

All Nextmv applications must follow the Nextmv application convention to work with the Nextmv platform.

Applications contain versions. An app version represents a specific executable code. You can think of a version like a Git commit tag. It is a snapshot of the code at a specific point in time.

The last core concept to know about are instances. An application instance is a representation of a version and optional configuration (options/parameters). You can think of an instance like an endpoint to execute your application.

Supported languages¶

Nextmv applications can be written in any programming language. You can find more information about this in the type property of the app.yaml manifest. The main supported languages are:

• python. Use for Python applications.
• java. Use for Java applications.
• binary. Use for compiled applications, such as Go, C, C++, Rust, etc.

Convention¶

For some executable code to be considered a Nextmv application, it must follow this convention:

• Have an app.yaml manifest file present at the root.
• Comply with json or multi-file to handle input/output operations.
• Work with one of the supported runtimes.

The following are optional but recommended:

• Print logs for debugging and troubleshooting. json apps expect logs to be printed to standard error (stderr), while multi-file apps can print logs to either standard output (stdout) or standard error (stderr).
• Receive options (parameters) via Command-Line (CLI) flags. The default format is -{{name}}={{value}}.
• Produce metrics to track information about a run.
• Produce assets, which can be visual assets.

We recommend you browse our community apps to see examples of applications that follow this convention.

json content format¶

An application that adheres to the json content format must comply with the following rules:

• Read input data as json from standard input (stdin).
• Write output data as json to standard output (stdout).
• Optionally, it can write logs to standard error (stderr), which will be captured and stored in the run's logs.
• The configuration.content.format property must be set to json in the app.yaml.
• To work with metrics, a .metrics property must be present at the root of the output json object.
• To work with visual assets, an .assets property must be present at the root of the output json object.

multi-file content format¶

An application that adheres to the multi-file content format must comply with the following rules:

• Read input data from one or more files. The path to those input files must be provided in the configuration.content.multi-file.input.path property in the app.yaml. The default value for this property is inputs.
• Write output data to one or more files. The path to those output files must be provided in the configuration.content.multi-file.output.solutions property in the app.yaml. The default value for this property is outputs/solutions.
• Optionally, it can write logs to either standard output (stdout) or standard error (stderr), which will be captured and stored in the run's logs.
• The configuration.content.format property must be set to multi-file in the app.yaml.
• To work with metrics, a .json file must be written to the path specified in the configuration.content.multi-file.output.metrics property in the app.yaml. The default value for this property is outputs/metrics.json.
• To work with visual assets, a .json file must be written to the path specified in the configuration.content.multi-file.output.assets property in the app.yaml. The default value for this property is outputs/assets/assets.json.