Skip to content

Glossary

Adam Hooper edited this page Nov 9, 2020 · 12 revisions

User-facing terms:

  • Workflow: A sort of document/project: contains all steps and renders as a whole.
  • Step: Unit of computation. Its input is a Table and its output is a Table. It holds a module, parameters and secrets.
  • Module: Function used in a Step. (It's a big block of Python code.) Each module accepts a certain set of parameters.
  • Params: Parameters to a module, stored on a Step. (We store them as JSON.)
  • Secrets: Special parameters that are as restrictive as possible while fulfilling the module's purpose. The workflow owner can set secrets (but usually can't read them). Other workflow viewers can see minimal identifying information ("logged in as [email protected]"). The module can see enough information to make API calls on behalf of the user -- in the case of OAuth2, the module sees client ID (for the module), client secret (for the module), and recent user access token (but not refresh token).
  • Tab: A visual helper for organizing steps.
  • Table: The data before and after each step.
  • Report: Sequence of blocks
  • Block: One element of a report. A block can be a Chart Block, Table Block or Text Block.

Developer-facing terms:

  • Delta: Database row containing a valid command -- one that can be applied that will change the workflow. Users create (and apply) Deltas using API methods. Everything the user can "undo" is stored in a Delta.
  • Command: A Delta's underlying logic. (Each Delta refers to a Command -- for instance, "Add Step".) Commands are used to validate and create a Delta, and to apply its "forward" (do) and "backward" (undo) logic.
  • Update: Package sent by the server that modifies all clients' Workflow state.
  • Mutation: Client-side optimistic Delta. The server ignores mutations (except to pass mutation IDs). The client stores "pending mutations" to derive optimistic Workflow state. For instance, when deleting a Step, the client stores a pending "delete step" mutation in its state (with a mutation ID); then it uses the server's API to create a "delete step" delta row in the database; then it waits for the server's "delete step" Update to arrive; then it applies the Update and deletes its local "delete step" mutation.