Application Structure

Any application folder deployed in Heim should contain certain configuration files, and follow a specific structure. This document contains a brief description of what an application should contain in order to be successfully deployed.

Application

The application layer is the top layer of the deployable units used in Heim.

An application can be seen as a wrapper, or container, that holds one or more component(s).

In order for an application to be successfully deployed in Heim, it needs to follow a certain file structure.

Applications also need to be set up with a specific application configuration file, the application.toml file, which defines the application.

Application – file structure

This example shows the file structure of a simple Rust application, ready to deploy in Heim:

• Directory{application-name}

  • Directorysrc

    • lib.rs
  • Directorytarget

    • …
  • .gitignore
  • Cargo.toml
  • component.toml
  • application.toml

The Rust application structure above can be compared to the structure of a C# application, also ready to deploy in Heim:

• Directory{application-name}

  • Directorywit

    • Directorydeps

      • …
      • world.wit
  • .gitignore
  • component.toml
  • application.toml
  • {application-name}.csproj
  • Program.cs

If you’ve read this document from the top, and are familiar with C#, Rust, or both languages, you’ve probably already spotted our two important configuration files:

• component.toml
• application.toml

The component.toml file is necessary for defining the contents of the application: one or more components. You can read more about the component layer of an application, in the next section of this document.

Read on to find out more about the application.toml concept.

Application.toml

Anything published and deployed with Heim is an application. Application folders should contain an application configuration file, application.toml. This configuration file contains a name for the application, values for environment variables, a component reference, and application trigger definitions.

This example shows a simple application configuration file (note the comments describing the various values):

application.toml

name = "neon_db_app"
component_target = 'neon_db_app:0.1.0'

[[trigger]]
type = 'http'
path = 'v1/neon-db-app' ## HTTP path to trigger on
method = 'GET' # HTTP method to trigger on

[env] # Assigns values to the environment variables defined for a component
NEON_CONNECTION_STRING = "postgresql://user_owner:PASSWORD@INSTANCE.aws.neon.tech/user?sslmode=require"

You can read more about this file in the application.toml document.

creating an application

You don’t have to set up the entire application structure necessary for an application to run in Heim.

We provide application templates you can use for creating a new application in Heim. You can read more about how to use application templates in our “Getting Started” document.

You can also check out our basic rust application example, which walks you through the creation of a new rust application in Heim. Find out more about templates in our Templates document, or check out our list of built-in templates

---

Component

Any application used in Heim contains one or more components. These components hold the source code of your application, and can be individually configured, which affects such matters as how you control the application, how the application build commands work, which environment variables an application should have available, and the component configuration contains metadata for defining and distinguishing between components used by an application.

The component concept used in Heim is based on the WebAssembly component model, which you can read more about in our general WebAssembly documentation.

Currently, application folders should contain one component configuration file, component.toml. This configuration file contains metadata, any commands that may be used to control a given component, configuration necessary to build the application in different modes, environmental variables used by the application, and more.

Any component should be configured with a .toml file. Currently, you need one component.toml.

This example shows a simple component configuration file (note the comments describing the various values):

component.toml

name = "neon-db-app" # Name of the component
version = "0.1.0"

[registry_metadata]
authors = ["Nor2"] # An array of authors
description = "Description of neon-db-app" # Description of the component
license = "MIT OR Apache-2.0 WITH LLVM-exception" # License for the component
categories = ["nor2"] # What the component should be catagorized under when released to a registry

[build.dev]
build = "cargo build --target=wasm32-wasip2" # The command to build the component from source
wasm_path = "./target/wasm32-wasip2/debug/neon_db_app.wasm" # The output wasm path

[build.prod]
build = "cargo build --target=wasm32-wasip2 --release"
wasm_path = "./target/wasm32-wasip2/release/neon_db_app.wasm"

[input.env] # Used to define a list of possible environment variables this component can consume
NEON_CONNECTION_STRING = { type = "String" }

You can read more about this configuration file in the component.toml document.

---

Summary

Any application that is to be deployed and published with the Heim tool needs to follow a specific application folder structure, and contain certain configuration files.

An application used in Heim consists of two layers:

layer	purpose
Application	An application is the top layer of a deployable unit in Heim. An application may contain one or more components.
Component	A component holds the source code used in your application. Components can be published and reused in other applications.

The configuration files you currently need in a valid application folder are:

file	purpose
component.toml	Configures a component contained in your application. Makes it possible to distinguish between components and to publish components later.
application.toml	Configures your application.