QuestDB JavaScript Client - v5.0.0
    Preparing search index...

    Interface QwpNodeClientOptions

    Node configuration for a combined pooled QWP ingress/egress client. One endpoint list and authentication are shared, while side-specific options remain explicit.

    interface QwpNodeClientOptions {
        cluster: QwpNodeWebSocketOptions;
        egress?: Omit<
            QwpNodeEgressOptions,
            "url"
            | "failoverUrls"
            | "authorization",
        >;
        ingress?: Omit<
            QwpNodeIngressOptions,
            "url"
            | "failoverUrls"
            | "authorization",
        >;
        lazyConnect?: boolean;
        pool?: QwpClientPoolOptions;
    }
    Index

    Properties

    Endpoints, authentication and the connection settings both sides share. Each URL may be an origin, a reverse-proxy base path, or an existing /write/v4 or /read/v1 endpoint; each side derives its own route.

    egress?: Omit<QwpNodeEgressOptions, "url" | "failoverUrls" | "authorization">

    The query sessions' options, on the same terms as ingress.

    ingress?: Omit<QwpNodeIngressOptions, "url" | "failoverUrls" | "authorization">

    The pooled senders' options. url, failoverUrls and authorization belong to cluster; any other connection setting given here overrides the cluster's for ingress only.

    lazyConnect?: boolean

    Coordinates a non-blocking startup: ingress connects in the background, using memory replay when store-and-forward is absent, and the egress pool remains cold until the first query. Conflicts with a positive queryPoolMin, an ingress initialConnectMode other than async, or ingress reconnect: false. This is the typed spelling of the lazy_connect key, which, as in the Java, Rust and Python clients, only the pooled client applies.