Architecture

Cascaide models you application(or parts of the application that need AI capabilities) as a Directed Graph. All parts are modelled as nodes in the graph - regardless of type: UI, llm invocations, etc.

Think of your application in terms of Graphs spread across execution environments (client/server) So in a simple application, we have

• Client side graph
• Server side graph
• Global application graph

Think of the client and server graphs as being subgraphs of the global graph. We do not declare the global graph, it is by default the union of the subgraphs.

Cascaide as a whole runs the global application graph. The subgraphs are executed on their respective environments and cascaide takes care of the orchestration.

The three pillars of Cascaide are:

• State
• Middlewares (Persistence, Hydration, Orchestration)
• Persistence Database

State

The state of the graph is stored in a redux store, initialised one per execution environment. The client side redux store holds information about the client side subgraph, while the server redux store holds information about the server side subgraph. All communication between subgraphs happen in the language of redux actions.

Middlewares

There are three middlewares that accompanies every redux store.

• Persistence Middleware
• Hydration Middleware
• Orchestration Middleware

Every action has to pass through these middlewares in the above order before it hits the store.

Note: Cacaide Lite only has Orchestration Middleware.

Persistence Database

While the redux stores records information about their local subgraph, the authoritative state of the global graph is stored in a DB. Three types of events are stored:

• Node Executions (inputs and outputs of every node)
• Context Events (state updates)
• Cascades (think of these as threads connecting node executions and context events)