Skip to main content

Flyte Domain Entity Model

The Flyte Domain Entity Model diagram represents the core objects used within the Flyte SDK to define and execute tasks and workflows.

Key findings from the codebase:

  • Task Definition: Tasks are defined using TaskTemplate (SDK-side) which contains the NativeInterface (Python types), resources, and retry strategies.
  • Interfaces: The SDK uses NativeInterface to represent Python-level type hints, which are then converted to the IDL-level TypedInterface. A TypedInterface consists of Variable objects, each mapping a name to a LiteralType.
  • Execution Model: In this version of the SDK (using flyteidl2), "Workflows" are implemented as "Pure Python Workflows" where a task can call other tasks. The execution is represented by a Run, which contains a root Action. Actions can be nested, representing the call graph of the execution.
  • Triggers: Automation and scheduling (traditionally LaunchPlan in Flyte) are handled via Trigger entities, which associate a task with an AutomationSpec (e.g., Cron or FixedRate).
  • Data Model: Data is passed between tasks as Literal objects, which can be scalars, collections, or maps.

The diagram shows the relationships between these entities, highlighting how SDK-side definitions (TaskTemplate) relate to remote execution objects (Run, Action) and the underlying IDL types (TypedInterface, Variable, Literal).

Key Architectural Findings:

  • Tasks are defined by TaskTemplate which holds a NativeInterface for Python-level type information.
  • NativeInterface is serialized into the IDL-level TypedInterface, which contains Variable definitions.
  • Executions are tracked via Run and Action entities; Action supports nesting to represent complex task call sequences.
  • Trigger entities manage task automation, replacing or augmenting the traditional LaunchPlan concept.
  • Data exchange is performed using Literal objects, which encapsulate various data types including scalars and collections.
Loading diagram...