Studio
Develop tasks and views in your browser.
Airplane Studio provides a rich development experience that allows you to quickly iterate on
Tasks and Views. Studio is functionally divided into three
parts:
- Left sidebar that lists Tasks, Views, Resources, and Config variables.
- Code editor that for quickly editing task and views.
- Main panel for executing tasks, previewing views, making configuration changes, etc.
Workspaces
Workspaces
When creating a task or view within Studio, you can choose where it is managed.
- Cloud workspaces allow you to build tasks directly within your Library, without setting up a local development environment.
- Local workspaces allow you to manage the code for your tasks and views on your machine. Local
workspaces require installing the Airplane CLI and running
airplane dev
to start the local dev server.
The
Explorer
tab in the left sidebar shows all tasks and views, including those in a local
workspace if a dev server is running. Tasks and views discovered within your the local workspace
will be demarcated by a computer icon () in the
Explorer
tab.Cloud workspace | Local workspace | |
---|---|---|
Create and edit SQL, REST, GraphQL, and Docker tasks | ✔ | ✔ |
Execute SQL, REST, GraphQL, and Docker tasks | ✔ | ✔ |
Create and edit JavaScript, Python, and Shell tasks | Coming soon! | ✔ |
Execute JavaScript, Python, and Shell tasks | Coming soon! | ✔ |
Create, edit, and preview views | Coming soon! | ✔ |
Create and edit remote configs and resources | ✔ | ✔ |
Create and edit local configs and resources | N/A | ✔ |
Cloud workspaces are great for getting started quickly and for making edits without running the
local dev server. If you're using Airplane on a team, we recommend using local workspaces in order
to integrate Airplane into your existing development flow (e.g. using version control, IDEs, etc.).
Starting the dev server
Starting the dev server
In order to develop in a local workspace, you must have the Airplane CLI
installed. Local workspaces in Studio work by making requests to a local dev server, a
trimmed-down version of the Airplane API server used to facilitate local development. To start up
the local dev server, run
airplane dev
:bashCopied1$ airplane dev2Discovering tasks and views... Registered 2 tasks and 1 view.34Watching for changes in: /home/bob/my-airplane-tasks5Changes to tasks and views will be applied automatically.67Started studio session at https://app.airplane.dev/studio (^C to quit)8Press ENTER to open the studio in the browser.
This command does a few things:
- Discovers local task and view definitions to load into the local dev server, which subsequently
get displayed in Studio.
airplane dev
takes in a single, optional, positional argument that indicates which directory to discover tasks and views from, e.g.airplane dev ~/my_apps
—this is known as the development root. Any task or view that has been discovered is said to be registered with Studio. By default, if no argument is passed, the CLI will attempt to discover definitions in the current directory and all nested subdirectories. It's also possible to pass in a filename as an argument, e.g.airplane dev my_task.task.yaml
—in this case, Studio will be used for the local development of a singular task or view. - Starts up an HTTP server that will respond to requests from Studio to execute tasks, load views, etc.
- Logs a URL through which you can access Studio.
Creating new tasks or views
Creating new tasks or views
Creating new tasks or views is easy in Studio. Click the
New
button in the upper right corner to
create a new task or view, or to initialize from an existing template.Editing existing tasks and views
Editing existing tasks and views
Studio provides a rich editing experience for tasks and views, whether by making changes through the
Configure panel or by editing more complex configurations through the code editor.
Configure panel
Configure panel
The
Configure
panel is used to edit task and view configuration, such as parameters and resource
attachments.Edits to tasks managed in a cloud workspace will be in "draft" mode until the changes are saved. For
tasks managed in a local workspace, changes are immediately reflected in code and will be visible in
the app once deployed.
Code editor
Code editor
When developing locally, Airplane Studio includes a full-featured code editor for tasks, views, or
any other files in your project. Changes are immediately saved to disk and reflected in Studio in
real time.
The code editor can be used to edit more complex task or view configurations that aren't supported
by the Configure panel—for example, configurations that utilize conditional logic or variable
references.
The code editor uses language servers to support linting, type checking, autocomplete, and
documentation on hover for Python, JavaScript/TypeScript, SQL, and YAML files. To enable or disable
language server support for a language, open the Studio settings and toggle the
Language server
setting in the Code editing
section.The code editor also supports formatting Python, JavaScript/TypeScript, SQL, and YAML files. Use
Shift+Option+F
(Mac) or Shift+Alt+F
(Windows/Linux) to format the current file. You can also
enable auto-formatting by toggling the Format on save
setting in the Code editing
section of the
Studio settings.To quickly open a file in your local editor, click the
Open in editor
button in the bottom right
corner of the Studio code editor.Executing tasks
Executing tasks
In addition to editing, Studio also supports executing tasks:
For more information on task execution in Studio, and the differences between task execution in
cloud and local workspaces, see the docs on task execution.
Loading views
Loading views
Views are not currently supported in cloud workspaces.
To load a view into Studio, simply select a view from the left sidebar (it may take a few seconds to
initially load the view):
Because the local dev server is handling the loading of the view, any edits you make to your view
will show up instantly in Studio—try it out!
Tasks in views
Tasks in views
If you reference a task in your view, that task must be registered
locally unless fallback is enabled, similar to
child runs.