Signals, transmitters & receivers

All data are signals, each signal follows a JTD (JSON Type Definition) schema. This enables the platform to filter out only compatible signals and statically validate all data with the added benefit of knowing that a configurable project is guaranteed to run as long as the runtime data follows the schema.

JSON Type Definition (JTD) schema

All data in mochabug Adapt, whether it comes from streams, constants, files or anywhere else is JSON. To describe the data and to make sure we can statically validate a project, mochabug Adapt uses JSON Type Definition (JTD)

Why JTD

JTD is used in mochabug Adapt over alternatives like JSON Schema because:

• It is small and unambiguous, every schema is built from exactly one of eight “forms.”
• It maps cleanly onto the type systems of common programming languages, which makes reliable code generation possible.
• A JTD schema is itself plain JSON.
• Since all data follows JTD, it’s possible to statically validate the whole project without using runtime data

JTD Forms

1. Empty — matches any value.

   {}

2. Type — one primitive (boolean, string, timestamp, float32/64, int8/16/32, uint8/16/32). A timestamp is an RFC 3339 string, and there is no 64-bit integer type.

   { "type": "string" }

3. Enum — a string from a fixed set. The set can’t be empty and can’t contain duplicates.

   { "enum": ["RED", "GREEN", "BLUE"] }

4. Elements — an array where every element matches the same schema.

   { "elements": { "type": "int32" } }

5. Properties — an object with known keys. Keys in properties are required, keys in optionalProperties may be left out, and a schema needs at least one of the two (additionalProperties defaults to false).

   {
     "properties": { "id": { "type": "string" } },
     "optionalProperties": { "note": { "type": "string" } }
   }

6. Values — a dictionary: any keys, one value schema.

   { "values": { "type": "float64" } }

7. Discriminator — a tagged union of Properties-form variants. A variant can’t be nullable and can’t define the tag property itself.

   { "discriminator": "kind", "mapping": { "a": { "properties": {} } } }

8. Ref — points at a named schema in root definitions.

   { "definitions": { "x": {} }, "ref": "x" }

Nullable and metadata

Two keywords can be added to a schema of any form:

• nullable — when true, the schema also accepts null.
• metadata — an object with free-form information about the schema, such as a description. It is ignored during validation.

   { "type": "string", "nullable": true, "metadata": { "description": "Middle name" } }

Example, click to expand

{
  "properties": {
    "shipping": {
      "enum": [
        "pickup",
        "standard",
        "express"
      ]
    },
    "termsAccepted": {
      "type": "boolean"
    },
    "products": {
      "elements": {
        "properties": {
          "quantity": {
            "type": "float64"
          },
          "unitPrice": {
            "type": "float64"
          },
          "productName": {
            "enum": [
              "widget-pro",
              "widget-basic",
              "gadget-plus",
              "gadget-std",
              "accessory"
            ]
          }
        },
        "optionalProperties": {
          "notes": {
            "type": "string"
          }
        }
      }
    }
  },
  "optionalProperties": {
    "deliveryDate": {
      "type": "timestamp"
    },
    "streetAddress": {
      "type": "string"
    },
    "city": {
      "type": "string"
    },
    "postalCode": {
      "type": "string"
    }
  }
}

Transmitters

Each vertex can transmit data in signals with it’s corresponding JTD schema. How the schema looks and the data is structured is up to the application author to decide. When looking at the transmitters you can view the schema as well as copy the JTD schema.

Tip

When creating constants, transforming data etc. copy the JTD schema of either the receiver or transmitter to make sure it’s compatible for the planned use.

Receivers

Each vertex can receive data in signals, the receiver has a defined JTD schema that only matching signals can be bound to. Only signals that has been transmitted in any upstream vertices are shown in the list of available signal.

Note

In case an optional signal is transmitted it can’t be bound to a required receiver, since we can’t guarantee that the signal will exist during runtime.

Binding signals

When binding signals only signals compatible with the JTD schema of the receiver will show up in the list of available signals.

Note

If a signal does not show up from a vertex upstream in the project, a likely cause is that transmitted signal is either not compatible with the receivers JTD schema or it is optional and the receiver signal is required.

Constants

Sometimes a project needs data that can be reused throughout a project while binding signals; like ids, folders etc. In that case you can use constants, constants can be bound as normal signals but exists in all vertices in the graph.

There are two ways in which you can create constants.

1. When you bind signals you have the option to bind a constant, either an existing compatible constant or you can create a new that uses the schema of the receiver.
2. From project settings you can define new constants, then you will have to define your schema manually or pick one of the existing ones.

To manage a projects constants, go into project settings > constants tab, from there it’s possible to delete or edit existing constants as well as create new ones.