Moost Event Lifecycle

When Moost receives an event (e.g. an HTTP request, a CLI command), it orchestrates a series of steps to route the event, initialize the necessary state, invoke the appropriate handler, and process interceptors and responses. Understanding this lifecycle helps developers anticipate where to integrate their logic — such as validation, authentication, logging, or error handling — and how to best leverage Moost’s composable and extensible architecture.

Diagram

Below is a representative diagram illustrating the lifecycle of a Moost event.

Detailed Steps

1. Incoming Event
   The lifecycle begins when Moost receives an event. This might be an HTTP request, a CLI command, or another type of event. At this point, Moost prepares to handle it by creating a fresh, isolated context.

2. Create Event Context
   Wooks uses createAsyncEventContext (What is Wooks?) to initialize a per-event context that persists across asynchronous operations. This ensures each event has its own storage for data, dependencies, and state.

3. Perform Routing
   The event is passed through the router (e.g., router.lookup) to find a matching handler. If a route matches, Wooks identifies which controller and handler method will process this event. If not found, a "Not Found" error is raised (Step 10).

4. Set Controller Instance in Event Context
   With a route found, Moost either creates or retrieves an appropriate controller instance. It attaches this controller to the event context, making its metadata accessible throughout the event lifecycle via useControllerContext composable.

5. Run Interceptors ‘before’ Hooks Moost resolves all applicable interceptors and runs their "before" hooks. Class-based interceptors are resolved through DI at this stage. Before hooks run before handler arguments are resolved, and can perform authentication checks, request transformations, or short-circuit the request entirely by calling reply(value). If an interceptor short-circuits, Moost skips to the after/error phase (Step 8). If an error occurs, Moost moves to error handling (Step 10).

6. Resolve Handler Arguments The handler’s parameters are resolved using pipelines. This includes resolve pipe, validation pipe (optional) and custom pipes (optional). If something goes wrong (e.g., invalid data), Moost proceeds to error handling (Step 10).

7. Call Handler Method With Resolved Arguments The handler method is invoked. It receives fully prepared arguments, so the logic within the handler can focus purely on business logic. If the handler throws an error, Moost transitions to the ‘error’ hooks of interceptors (Step 9). If an error occurs beforehand, Step 10 is triggered.

8. Run Interceptors ‘after’ Hooks If the handler succeeded, Moost executes the "after" hooks of interceptors. This could involve adding headers, logging success, or modifying the response. Errors here also lead to Step 10.

9. Run Interceptors ‘error’ Hooks If the handler failed, interceptors’ "error" hooks allow transforming or logging the error, and possibly returning an alternate response. If an error arises in the error hooks, Moost moves to Step 10.

10. Raise Error If any previous step encounters an error, Moost halts the normal flow and produces an error response. The exact nature of the error response depends on the event type and any interceptors or error handlers that may have modified the error along the way.

11. Process Final Response Wooks then formats the final response based on the event type (e.g., JSON response for HTTP, textual output for CLI). If this step fails, an error response is raised (Step 10). (What is Wooks?)

12. Return Response to Event Origin Finally, the processed (or error) response is returned to the event’s origin, concluding the event lifecycle.

Summary

Whether you’re validating input data, enforcing security policies, logging metrics, or formatting output, understanding and leveraging these lifecycle stages ensures that your Moost application remains maintainable, testable, and adaptable to evolving requirements.