tflo

Interop backlog

Designed integrations between tflo and mature CEP / streaming engines — deferred until concrete user demand surfaces. The framing across all entries is composability, not substitution: tflo brings what the host engine cannot (typed Absent, typed Signal, edge / WASM / embedded-Rust deployment); the host brings what tflo does not (distributed runtime, exactly-once via 2PC, savepoints, broad connector catalogs).

Documenting the shape here, before any build, prevents wheels from being re-invented and lets reviewers reject ad-hoc integration PRs by pointing at the intended design.

tflo-flink — Flink integration Backlog

tflo-core compiled to a shared library; Flink calls via JNI. A thin Java wrapper exposes TfloKeyedProcessFunction<K, R, S> to Flink job authors. In jurisdictions where JNI is off-limits, the fallback is a sidecar process with a small binary protocol.

Two integration directions, both supported:

  • Flink → tflo: Flink hosts the distributed runtime; tflo runs per-key detector logic inside a KeyedProcessFunction. The host owns watermarks, exactly-once, scaling, savepoints. tflo owns signal logic and typed Absent.
  • tflo → Flink: tflo runs at the edge (gateway, browser, embedded service), emits typed Signal<Mode, Payload> events that get shipped to a central Flink job for aggregation and joining with reference data.

Standalone value: Flink users gain typed Absent (named reasons for missing values, which Flink itself does not provide) and edge-side signal pre-processing in deployment shapes the JVM cannot reach. Both engines stay in their best lane: Flink owns the cluster; tflo owns the signal logic.

tflo-beam — Apache Beam adapter Backlog

A Beam DoFn (Java) that wraps a tflo graph the same way tflo-flink wraps it inside a Flink KeyedProcessFunction. The shared-library / JNI layer is shared with tflo-flink; the Java companion is Beam-specific. Strictly built after tflo-flink validates the JNI pattern. Portability is the payoff: choose Dataflow for managed, Flink for self-hosted, or Spark for batch-heavy without rewriting the signal logic.

tflo-kstreams — Kafka Streams adapter Backlog

A Kafka Streams Processor<K, V> (Java) wrapping a tflo graph; same shared-library / JNI substrate as tflo-flink. For Kafka shops, the operational surface stays just Kafka — no JobManager, no separate state cluster. Postponed until tflo-flink and tflo-beam validate the JNI pattern.

Esper integration

Explicitly not planned. Esper is in maintenance mode upstream; the integration cost-benefit is poor. Users who need it can have tflo emit typed Signal events to a topic that Esper consumes — a normal producer / consumer pattern, no special integration crate required.

Promotion criteria

An entry above leaves the backlog when, in order:

  1. A concrete user requests the integration with a clear use case.
  2. The use case is consistent with the "supplement, not replace" framing.
  3. The standalone story (Phases 0–3 of the closure plan) is complete and stable.

Canonical source: docs/interop-backlog.md.

Related: Non-goals · Positioning