Cascaide vs Cascaide Lite

There are two main ways of using Cascaide to build an AI web application. Both use the same libraries, but the way you use it, specifically, what you send from client changes.

Cascaide

The durable, full version of Cascaide. It requires a postgres DB for durability.

Use it if:

• You need full audit trails
• Need to display filtered conversation traces on the frontend
• Robust recovery from crashes

In short, use it if you’re building a commercial application.

Note on debugging: You can use redux devtools to observe the state, but you don’t have full view with this alone as you are unlikely to surface full agent traces to the frontend. You can set up Sonar Lite to get full observability during development.

Cascaide Lite

Non durable version. Easier to set up, great for internal tools, services and hobby projects.

Use it if:

• You are comfortable surfacing full agent traces to the frontend
• You don’t need full audit logs and durability in production
• You are okay wiring full histories from the frontend

Note on debugging: In cascaide lite, you get full observability with redux devtools alone.

The Difference in Implementation : A Practical Note

Key practical implementation differences can be summed up as follows

Migrating from Cascaide Lite to Cascaide or Vice Versa

Migration from Cascaide Lite to Cascaide is straightforward. Agent code remains the same, all that changes are configurations and addActiveNode payloads from all client side nodes.

• create and pass in persistence and action endpoints to WorkflowProvider
• initialise and pass in persistor to WorkflowHandler
• modify all addActiveNode invocation on the client to send just the latest message instead of the full cascade history

If your migrating the other direction, simply remove the persistence endpoint, set persistor = undefined in the WorkflowHandler and modify the addActiveNode invocations on the client to send the full cascade history.