Saltar a contenido

ADR-022: CEL para expressions

  • Status: Accepted
  • Date: 2026-05-14
  • Tags: core, expressions, language

Context and Problem Statement

BPMN usa FEEL para conditions, mappings, timer durations. Camunda usa feel-scala (~50K LOC). MVP necesita expression engine. ¿Build, reuse feel-scala, o usar alternative?

Decision Drivers

  • feel-scala is JVM-only (huge dependency)
  • Building FEEL parser from scratch = 3-6 meses
  • CEL is production-grade, multi-language
  • Pragmatic Camunda compatibility (subset coverage 80%)
  • Performance crítico (hot path)

Considered Options

  1. CEL (Common Expression Language by Google)
  2. Build FEEL subset propio
  3. Integrate feel-scala via subprocess
  4. JSONata
  5. Multiple engines pluggable

Decision Outcome

Chosen option: CEL principal + FEEL-lite shim para compatibility porque: - CEL production-grade (Istio, Kubernetes, GCP IAM use it) - Multi-language SDKs maduros (Go, Java, TS, Python) - Performance excellent (~5μs cached) - FEEL-lite shim (~2K LOC) cubre 80% migrated Camunda BPMN

Positive Consequences

  • No build of full parser
  • Performance excellent
  • Multi-language for SDKs
  • Postgres extension available
  • Camunda BPMN migration possible (with conversion tool)

Negative Consequences

  • NOT 100% BPMN spec compliant
  • Migration tool required from FEEL
  • Some FEEL features lost (DMN-specific especialmente)
  • Two engines maintained (CEL + FEEL-lite)

Implementation strategy

Ver analysis/feel-expressions-strategy para detalles.

Phase 1: - CEL como primary expression engine - FEEL-lite shim (~2K LOC) para subset común de FEEL - Conversion tool mvp-cli bpmn convert --from=camunda-feel --to=cel

Phase 2 (opcional): - feel-scala subprocess para 100% FEEL compatibility si demand real