The Fluence Labs Developer Hub

Welcome to the Fluence Labs developer hub. You'll find comprehensive guides and documentation to help you start working with Fluence Labs as quickly as possible, as well as support if you get stuck. Let's jump right in!

Should you have any questions, feel free to join our Discord or Telegram!

Get Started

Service creation

Uploading modules, creating services

To create a service, you need three things:

  • WebAssembly modules (.wasm) that define the logic of the service
  • Blueprint that specifies the name and id of the service, as well as its dependencies
  • A node or nodes for hosting the service

Modules

Each service can include three possible kinds of .wasm modules:

  1. Facade module
    This module provides an API that is callable from AIR scripts. Facade modules
    usually import pure and effector modules and provide a clear API over them.

📘

Each service must contain a single facade module.

  1. Pure modules
    These are your regular .wasm modules, but with a fundamental limitation: they
    cannnot cause any effects, such as accessing the file system, calling OS binaries
    or functions from non-pure modules.

  2. Effector modules
    These modules do not have any limitations. They can modify files, run external
    programs, etc. All effects occur through the WebAssembly system interface (WASI).

You can have a service consisting of a single module. This module will automatically be a facade module.

To use a module as a part of a service, this module must be uploaded to the node where the service will be created and hosted.

To upload a new module, you can use the add_module built-in function.

To learn how to add modules from JS SDK, refer to JS SDK doc.

Blueprints

To create a service, the node needs information about what modules to use. The node takes it from a blueprint. The blueprint is just a configuration object of the following structure:

{
    "id": "uuid-1234-...",
  "name": "some name",
  "dependencies": [ "module_a", "module_b", "facade_module" ]
}

Each blueprint is referred to by its id, also called blueprint_id in some built-in functions. Dependencies in blueprints are specified as the list of module names, which are not checked for validity. So you do not need to synchronize adding blueprints and modules.

You can use the add_blueprint built-in function to add new blueprints to the node where you want to create the service.

To learn how to add blueprints from JS SDK, refer to JS SDK doc.

Once the blueprint is added to the node, it remains there and will be used when creating the service.

Create service

After you have developed the service modules and uploaded them to the node along with the blueprint specifying which modules to use, you are ready to create the service.

To draw an analogy from programming languages, blueprints are like classes, and services are like instances, that is, concrete objects created.

To create a service, you need to call the srv create built-in function.

To learn how to create services in JS, refer to JS SDK doc.

Environment variables

TBD

Remove service

TBD

Updated about a month ago

Service creation


Uploading modules, creating services

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.