Skip to content

App Execution Flow

For app developers, it's important to have a full understanding of how the Compute Engine executes the application's code when a user interacts with it on the platform.

As stated previously, an application is executed by running the so-called Execution Methods based on the user's interactions with the app. In Execution Stages, we'll explore the sequence in which these methods are executed and identify which methods are run for each type of user interaction.

We'll also explore what happens under the hood when you Interact with an app, and how it relates to the Compute Engine.

And finally, we'll take a brief look into the execution flow of Multi-Stage Apps.

Execution Stages

Let's now show how the different Execution Methods are executed for the following user interactions with an application, or with the Compute Engine:

  • Opening an App
  • Changing / Refreshing Inputs
  • Running a Calculation
  • Getting the App's Parameters
Step Execution Method Opening an App Changing Inputs Running a Calculation Getting the App's Parameters
register_parameters
expose_parameters
build_report
build_summary

Execution Sequence

Please note that, regardless of the user interaction, the methods are always executed in the sequence listed in the table, from top to bottom.

Interaction between the Compute Platform and the Engine

Whenever you interact with an app—whether it's changing an input or running a computation — a request for those changes is made and sent to the Compute Engine. The Compute Engine then executes the appropriate Execution Methods based on the user's interaction.

Below is a diagram that illustrates this interaction:

stateDiagram
    direction LR
    Platform --> Solver: Request (1)
    Platform: compute.build
    Engine: Compute Engine
    state Engine {
    %%Direction is not working... These directions don't make sense, but render the correct diagram
        direction RL
        AppSession: App Session Results
        Solver: App Solver
        Solver --> AppSession: Add Parameters to Store (2)
        state AppSession {
            direction LR
            Parameter1
            Parameter2
            Parameter3
        }
        AppSession --> Solver: Return Artifacts (3)
    }
    Solver --> Platform: Response (4)
  1. Request: When you interact with an app, a request is sent to the App Solver with a new state. This new state includes changes in input parameters, which Execution Methods to be executed, whether to run the computation, and other metadata.
  2. Add Parameters to Store: The App Solver will execute each Execution Method specified in the Request, in sequence. During this process, parameters will be added to the App Session Results, a virtual memory space available during each request-response cycle, using Content Methods.
  3. Return Artifacts: Once all Execution Methods have been executed, the App Session Results are returned as an ordered list of artifacts representing the processed parameters.
  4. Response: The artifacts are packaged and returned to the compute.build client, where they will be rendered on the app's page.

This interaction between the platform and the Compute Engine is RESTful, meaning that the Compute Engine does not retain session state from previous requests and that each new request is processed independently of earlier ones.

Multi-Stage Apps

For Multi-Stage applications, this statement is a bit more nuanced, as we need to maintain state (e.g., inputs, calculations) from previous stages and reuse them in subsequent stages. This will be explained in greater detail in Multi-Stage Execution.

Multi-Stage Execution

The execution of a Multi-Stage application is a bit different from Single-Stage apps, as some form of state must be maintained between stages.

Master App

This app should not have any Execution Methods apart from the class's constructor. To designate this app as the Master App of a Multi-Stage application, you need to add the following sections to the app code:

  • In the app_meta.yaml file, set is_multi_stage=True to specify the app as the Master App.
  • Call the set_app_stages() method in the app's constructor __init__ to define the sequence of Stage Apps.

You will also need to include all Stage Apps in the additional_apps field of the Collection Requirements file.

Stage Apps

These apps do not require any additional parameters in the app code. However, you will have access to additional methods to retrieve data from previous stages for use in the current stage:

Multi-Stage Example

For an example of how to build a Multi-Stage app, check out the Volume of Boxes (Multi-Stage) tutorial.