@authzed/authzed-node/dist/src/authzedapi/authzed/api/materialize/v0/watchpermissionsets.grpc-client.d.ts

authzed client for nodejs

import type { BinaryWriteOptions } from "@protobuf-ts/runtime";
import type { BinaryReadOptions } from "@protobuf-ts/runtime";
import type { LookupPermissionSetsResponse } from "./watchpermissionsets.js";
import type { LookupPermissionSetsRequest } from "./watchpermissionsets.js";
import type { WatchPermissionSetsResponse } from "./watchpermissionsets.js";
import type { WatchPermissionSetsRequest } from "./watchpermissionsets.js";
import * as grpc from "@grpc/grpc-js";
/**
 * @generated from protobuf service authzed.api.materialize.v0.WatchPermissionSetsService
 */
export interface IWatchPermissionSetsServiceClient {
    /**
     * WatchPermissionSets returns a stream of changes to the sets which can be used to compute the watched permissions.
     *
     * WatchPermissionSets lets consumers achieve the same thing as WatchPermissions, but trades off a simpler usage model with
     * significantly lower computational requirements. Unlike WatchPermissions, this method returns changes to the sets of permissions,
     * rather than the individual permissions. Permission sets are a normalized form of the computed permissions, which
     * means that the consumer must perform an extra computation over this representation to obtain the final computed
     * permissions, typically by intersecting the provided sets.
     *
     * For example, this would look like a JOIN between the
     * materialize permission sets table in a target relation database, the table with the resources to authorize access
     * to, and the table with the subject (e.g. a user).
     *
     * In exchange, the number of changes issued by WatchPermissionSets will be several orders of magnitude less than those
     * emitted by WatchPermissions, which has several implications:
     * - significantly less resources to compute the sets
     * - significantly less messages to stream over the network
     * - significantly less events to ingest on the consumer side
     * - less ingestion lag from the origin SpiceDB mutation
     *
     * The type of scenarios WatchPermissionSets is particularly well suited is when a single change
     * in the origin SpiceDB can yield millions of changes. For example, in the GitHub authorization model, assigning a role
     * to a top-level team of an organization with hundreds of thousands of employees can lead to an explosion of
     * permission change events that would require a lot of computational resources to process, both on Materialize and
     * the consumer side.
     *
     * WatchPermissionSets is thus recommended for any larger scale use case where the fan-out in permission changes that
     * emerges from a specific schema and data shape is too large to handle effectively.
     *
     * The API does not offer a sharding mechanism and thus there should only be one consumer per target system.
     * Implementing an active-active HA consumer setup over the same target system will require coordinating which
     * revisions have been consumed in order to prevent transitioning to an inconsistent state.
     *
     * @generated from protobuf rpc: WatchPermissionSets(authzed.api.materialize.v0.WatchPermissionSetsRequest) returns (stream authzed.api.materialize.v0.WatchPermissionSetsResponse);
     */
    watchPermissionSets(input: WatchPermissionSetsRequest, metadata?: grpc.Metadata, options?: grpc.CallOptions): grpc.ClientReadableStream<WatchPermissionSetsResponse>;
    watchPermissionSets(input: WatchPermissionSetsRequest, options?: grpc.CallOptions): grpc.ClientReadableStream<WatchPermissionSetsResponse>;
    /**
     * LookupPermissionSets returns the current state of the permission sets which can be used to derive the computed permissions.
     * It's typically used to backfill the state of the permission sets in the consumer side.
     *
     * It's a cursored API and the consumer is responsible to keep track of the cursor and use it on each subsequent call.
     * Each stream will return <N> permission sets defined by the specified request limit. The server will keep streaming until
     * the sets per stream is hit, or the current state of the sets is reached,
     * whatever happens first, and then close the stream. The server will indicate there are no more changes to stream
     * through the `completed_members` in the cursor.
     *
     * There may be many elements to stream, and so the consumer should be prepared to resume the stream from the last
     * cursor received. Once completed, the consumer may start streaming permission set changes using WatchPermissionSets
     * and the revision token from the last LookupPermissionSets response.
     *
     * @generated from protobuf rpc: LookupPermissionSets(authzed.api.materialize.v0.LookupPermissionSetsRequest) returns (stream authzed.api.materialize.v0.LookupPermissionSetsResponse);
     */
    lookupPermissionSets(input: LookupPermissionSetsRequest, metadata?: grpc.Metadata, options?: grpc.CallOptions): grpc.ClientReadableStream<LookupPermissionSetsResponse>;
    lookupPermissionSets(input: LookupPermissionSetsRequest, options?: grpc.CallOptions): grpc.ClientReadableStream<LookupPermissionSetsResponse>;
}
/**
 * @generated from protobuf service authzed.api.materialize.v0.WatchPermissionSetsService
 */
export declare class WatchPermissionSetsServiceClient extends grpc.Client implements IWatchPermissionSetsServiceClient {
    private readonly _binaryOptions;
    constructor(address: string, credentials: grpc.ChannelCredentials, options?: grpc.ClientOptions, binaryOptions?: Partial<BinaryReadOptions & BinaryWriteOptions>);
    /**
     * WatchPermissionSets returns a stream of changes to the sets which can be used to compute the watched permissions.
     *
     * WatchPermissionSets lets consumers achieve the same thing as WatchPermissions, but trades off a simpler usage model with
     * significantly lower computational requirements. Unlike WatchPermissions, this method returns changes to the sets of permissions,
     * rather than the individual permissions. Permission sets are a normalized form of the computed permissions, which
     * means that the consumer must perform an extra computation over this representation to obtain the final computed
     * permissions, typically by intersecting the provided sets.
     *
     * For example, this would look like a JOIN between the
     * materialize permission sets table in a target relation database, the table with the resources to authorize access
     * to, and the table with the subject (e.g. a user).
     *
     * In exchange, the number of changes issued by WatchPermissionSets will be several orders of magnitude less than those
     * emitted by WatchPermissions, which has several implications:
     * - significantly less resources to compute the sets
     * - significantly less messages to stream over the network
     * - significantly less events to ingest on the consumer side
     * - less ingestion lag from the origin SpiceDB mutation
     *
     * The type of scenarios WatchPermissionSets is particularly well suited is when a single change
     * in the origin SpiceDB can yield millions of changes. For example, in the GitHub authorization model, assigning a role
     * to a top-level team of an organization with hundreds of thousands of employees can lead to an explosion of
     * permission change events that would require a lot of computational resources to process, both on Materialize and
     * the consumer side.
     *
     * WatchPermissionSets is thus recommended for any larger scale use case where the fan-out in permission changes that
     * emerges from a specific schema and data shape is too large to handle effectively.
     *
     * The API does not offer a sharding mechanism and thus there should only be one consumer per target system.
     * Implementing an active-active HA consumer setup over the same target system will require coordinating which
     * revisions have been consumed in order to prevent transitioning to an inconsistent state.
     *
     * @generated from protobuf rpc: WatchPermissionSets(authzed.api.materialize.v0.WatchPermissionSetsRequest) returns (stream authzed.api.materialize.v0.WatchPermissionSetsResponse);
     */
    watchPermissionSets(input: WatchPermissionSetsRequest, metadata?: grpc.Metadata | grpc.CallOptions, options?: grpc.CallOptions): grpc.ClientReadableStream<WatchPermissionSetsResponse>;
    /**
     * LookupPermissionSets returns the current state of the permission sets which can be used to derive the computed permissions.
     * It's typically used to backfill the state of the permission sets in the consumer side.
     *
     * It's a cursored API and the consumer is responsible to keep track of the cursor and use it on each subsequent call.
     * Each stream will return <N> permission sets defined by the specified request limit. The server will keep streaming until
     * the sets per stream is hit, or the current state of the sets is reached,
     * whatever happens first, and then close the stream. The server will indicate there are no more changes to stream
     * through the `completed_members` in the cursor.
     *
     * There may be many elements to stream, and so the consumer should be prepared to resume the stream from the last
     * cursor received. Once completed, the consumer may start streaming permission set changes using WatchPermissionSets
     * and the revision token from the last LookupPermissionSets response.
     *
     * @generated from protobuf rpc: LookupPermissionSets(authzed.api.materialize.v0.LookupPermissionSetsRequest) returns (stream authzed.api.materialize.v0.LookupPermissionSetsResponse);
     */
    lookupPermissionSets(input: LookupPermissionSetsRequest, metadata?: grpc.Metadata | grpc.CallOptions, options?: grpc.CallOptions): grpc.ClientReadableStream<LookupPermissionSetsResponse>;
}