@authzed/authzed-node/src/authzedapi/authzed/api/materialize/v0/watchpermissions.grpc-client.ts

authzed client for nodejs

// @generated by protobuf-ts 2.9.1 with parameter generate_dependencies,long_type_string,client_grpc1
// @generated from protobuf file "authzed/api/materialize/v0/watchpermissions.proto" (package "authzed.api.materialize.v0", syntax proto3)
// tslint:disable
import { WatchPermissionsService } from "./watchpermissions.js";
import type { BinaryWriteOptions } from "@protobuf-ts/runtime";
import type { BinaryReadOptions } from "@protobuf-ts/runtime";
import type { WatchPermissionsResponse } from "./watchpermissions.js";
import type { WatchPermissionsRequest } from "./watchpermissions.js";
import * as grpc from "@grpc/grpc-js";
/**
 * @generated from protobuf service authzed.api.materialize.v0.WatchPermissionsService
 */
export interface IWatchPermissionsServiceClient {
    /**
     * WatchPermissions returns a stream of PermissionChange events for the given permissions.
     *
     * WatchPermissions is a long-running RPC, and will stream events until the client
     * closes the connection or the server terminates the stream. The consumer is responsible of
     * keeping track of the last seen revision and resuming the stream from that point in the event
     * of disconnection or client-side restarts.
     *
     * 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.
     *
     * Usage of WatchPermissions requires to be explicitly enabled on the service, including the permissions to be
     * watched. It requires more resources and is less performant than WatchPermissionsSets. It's usage
     * is only recommended when performing the set intersections of WatchPermissionSets in the client side is not viable
     * or there is a strict application requirement to use consume the computed permissions.
     *
     * @generated from protobuf rpc: WatchPermissions(authzed.api.materialize.v0.WatchPermissionsRequest) returns (stream authzed.api.materialize.v0.WatchPermissionsResponse);
     */
    watchPermissions(input: WatchPermissionsRequest, metadata?: grpc.Metadata, options?: grpc.CallOptions): grpc.ClientReadableStream<WatchPermissionsResponse>;
    watchPermissions(input: WatchPermissionsRequest, options?: grpc.CallOptions): grpc.ClientReadableStream<WatchPermissionsResponse>;
}
/**
 * @generated from protobuf service authzed.api.materialize.v0.WatchPermissionsService
 */
export class WatchPermissionsServiceClient extends grpc.Client implements IWatchPermissionsServiceClient {
    private readonly _binaryOptions: Partial<BinaryReadOptions & BinaryWriteOptions>;
    constructor(address: string, credentials: grpc.ChannelCredentials, options: grpc.ClientOptions = {}, binaryOptions: Partial<BinaryReadOptions & BinaryWriteOptions> = {}) {
        super(address, credentials, options);
        this._binaryOptions = binaryOptions;
    }
    /**
     * WatchPermissions returns a stream of PermissionChange events for the given permissions.
     *
     * WatchPermissions is a long-running RPC, and will stream events until the client
     * closes the connection or the server terminates the stream. The consumer is responsible of
     * keeping track of the last seen revision and resuming the stream from that point in the event
     * of disconnection or client-side restarts.
     *
     * 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.
     *
     * Usage of WatchPermissions requires to be explicitly enabled on the service, including the permissions to be
     * watched. It requires more resources and is less performant than WatchPermissionsSets. It's usage
     * is only recommended when performing the set intersections of WatchPermissionSets in the client side is not viable
     * or there is a strict application requirement to use consume the computed permissions.
     *
     * @generated from protobuf rpc: WatchPermissions(authzed.api.materialize.v0.WatchPermissionsRequest) returns (stream authzed.api.materialize.v0.WatchPermissionsResponse);
     */
    watchPermissions(input: WatchPermissionsRequest, metadata?: grpc.Metadata | grpc.CallOptions, options?: grpc.CallOptions): grpc.ClientReadableStream<WatchPermissionsResponse> {
        const method = WatchPermissionsService.methods[0];
        return this.makeServerStreamRequest<WatchPermissionsRequest, WatchPermissionsResponse>(`/${WatchPermissionsService.typeName}/${method.name}`, (value: WatchPermissionsRequest): Buffer => Buffer.from(method.I.toBinary(value, this._binaryOptions)), (value: Buffer): WatchPermissionsResponse => method.O.fromBinary(value, this._binaryOptions), input, (metadata as any), options);
    }
}