JSONata vs. JavaScript: Choosing a Transformation Engine

When building Crate’s plugin system for API transformations, we had a choice: let users run arbitrary JavaScript or use a declarative language like JSONata.

Safety vs. Flexibility

Node.js gateways (like Express Gateway) allow you to run arbitrary JavaScript. This is powerful, but it’s a security nightmare. A single infinite loop in a script can take down your entire cluster.

JSONata is Declarative. It defines what you want, not how to loop. This makes it impossible to write an infinite loop.

Crate Config Example:

# crate.yaml
pipelines:
  order-service:
    transform:
      engine: jsonata
      expression: |
        {
          "orderId": payload.id,
          "total": $sum(payload.items.price)
        }        

This ensures that even if a developer writes a complex transformation, the gateway engine maintains its memory and CPU limits.

Running untrusted JavaScript at the gateway level is a security and performance nightmare. JSONata is deterministic and safe by design. It allows for complex data reshaping—aggregations, conditional logic, and deep object mapping—without the risk of infinite loops or memory leaks.

Performance at Scale Because we use Go, we can execute JSONata transformations with high efficiency. We are currently theorizing the “Safety Sandbox” to ensure that even the most complex queries remain within our strict millisecond latency budgets.