Native Applications are containerized web applications that run on Edge. They provide a frontend web user interface, with backends that can perform long running computational tasks. Native Applications can be run on a variety of Compute Profiles that feature a wide array of memory, CPU, and GPU capabilities.
When a user launches a Native Application, Edge will create and host an individual instance for that user. Edge Compute Profiles can be assigned more computational resources than a traditional desktop application. Users are free to interact with the Native Application while long running compute tasks run on Edge in the background, without tying up local desktop resources.
Native Applications also have access to Edge resources, such as data stored in Edge. They can perform tasks on files without having to transfer them to a user's local system. In addition, they benefit from Edge's built-in Authentication workflow.
A Compute Profile in Edge is a set of computational resources
(CPU, GPU, memory) that will be used by a Edge Native app. A profile
essentially provides the equivalent of a dedicated virtual machine.
Internally, the profile is used to construct a Kubernetes "pod" to run the app with at least the requested resources. Having a standard set of profiles allows fast re-use of the underlying virtual machine infrastructure; when one application exits, another app needing similar resources can run immediately.
Application instances can be started with a recommended profile, or one may be selected by a user by opening the Application tile's start menu and selecting a Compute Profile:
During application registration, you can optionally select a "recommended" profile from a number of predefined compute profiles:
|Profile Name||Display Name||CPUs||GPUs||Memory (Gb)|
Authoring a Native Application
The Edge Native App Example provides a convenient template for developing Native Applications. It consists of a Flask backend, React frontend client and CI tools. Authoring a Native Application typically involves the following tasks:
- Create a Native Application using the Edge Native App Example as a template
- Develop and test the Native Application locally
- Build a Docker image and publish it
- Register the application on Edge
The example application CI tools are ideal for performing these tasks:
python -m ci watch backendruns the application in a local development mode with live reload
python -m ci watch frontendcompiles the React frontend and provides live reload
python -m ci buildwill create a local Docker image
python -m ci startlaunches a local Jupyter instance for testing
python -m ci publishpublishes the Docker image to an image repository for deployment on Edge
Native Application Architecture
Native Applications typically consist of a backend API and a frontend
client. The backend is also responsible for serving the frontend files
for a browser to render the frontend. When a user launches an instance
of the application Edge will provide routing to the backend through
The Edge Native App Example performs face detection image processing on any images that are submitted via drag and drop. Native Applications should perform long running compute tasks in a non-blocking fashion using subprocesses.
- The backend receives new
from the frontend via
- Long running tasks are started in
multiprocessinglibrary, and a task ID is returned to the frontend
- Results are stored in a shared dictionary
- The frontend periodically queries the backend for the result of any operations.
Native Application Requirements
There are several requirements for the application to provide long running background computation and to work with Edge's Authentication system and routing. We will use the Edge Native App Example as a reference for how these requirements can be implemented. This example application uses Flask as a backend and React as a frontend.
Edge provides several environment variables to Native Application instances. These environment variables are required for configuring application routing and integrating with Edge's authentication system.
Edge handles all of the details of logging a user in. The Native Application only needs to define decorators for checking a user's login state with Edge and define an endpoint for handling Edge's authentication callback. For more details, see the README.md in the Native Application Example GitHub Repository.
Edge automatically terminates Native Application instances that are
idle. The application backend should periodically report activity to
Edge by performing a
POST operation. In the example application, this
is done using a track_activity
Edge creates a unique path for each user's Native Application instances. This path is provided to the Native Application instance via environment variables, and a user will be redirected to this path on Edge's web domain. For details of how to configure routing, see the README in the Native Application Example GitHub Repository.
Publishing a Native Application
Native Applications can be published by pushing the application's
Docker image to a Docker image repository and registering the
application on Edge. It is recommended that
quay.io be used as a
Docker image repository host. To publish a Native Application, you will
need the following:
- A provisioned Docker image repository, such as a repository on
- A deployment username and password for the Docker image repository
- A built container that has been pushed to the Docker image repository
The instructions for
Publishing an Application are designed for publishing a Native Application. When
AppVersion, you must specify that the version type is
AppKindEnum.Native and provide the address of the Docker image
repository. In addition, you must register a
ServerInfo object with
the Application that provides the registry domain, username and password
for pulling the Docker image.
Dashboard Applications are a lightweight type of Native application. Like other Native Applications, they are containerized web applications that are launched as instances for each user, integrate with Edge authentication, and have access to Edge resources. Dashboards are hosted on a smaller Dashboard Compute Profile that is designed to remain continuously running once launched. They are well suited for serving dynamic metrics displays and plots, as well as performing low-latency, low-compute tasks.
Authoring Dashboard Applications
The Edge Dashboard App
provides a convenient template for developing Dashboard Applications. It
consists of a Flask backend, React frontend client with
CI tools. The authoring process is very similar to
Authoring a Native Application.
The major difference between Native and Dashboard Applications are that
Dashboards should be published with the
edge.dashboard Compute Profile
as the recommended profile. This Compute Profile allocates 0.25
Gigabytes of memory and half of a CPU. The following code should be used
version1 = AppVersion(
title="Dashboard App Demo, v1.0.0",
description="Demonstration of a Dashboard application",
edge.dashboard profile is inexpensive. Instances launched with
this profile can be kept continuously running for a user once launched.
If a user has previously launched a Dashboard, they may access it again.
Edge will skip the provisioning process and redirect the user to their