@authzed/authzed-js-node
Version:
authzed js client for nodejs
75 lines • 5.46 kB
JavaScript
// @generated by protobuf-ts 2.9.1 with parameter generate_dependencies,long_type_string,client_grpc1
// @generated from protobuf file "authzed/api/materialize/v0/watchpermissionsets.proto" (package "authzed.api.materialize.v0", syntax proto3)
// tslint:disable
import { WatchPermissionSetsService } from "./watchpermissionsets.js";
import * as grpc from "@grpc/grpc-js";
/**
* @generated from protobuf service authzed.api.materialize.v0.WatchPermissionSetsService
*/
export class WatchPermissionSetsServiceClient extends grpc.Client {
_binaryOptions;
constructor(address, credentials, options = {}, binaryOptions = {}) {
super(address, credentials, options);
this._binaryOptions = binaryOptions;
}
/**
* 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, metadata, options) {
const method = WatchPermissionSetsService.methods[0];
return this.makeServerStreamRequest(`/${WatchPermissionSetsService.typeName}/${method.name}`, (value) => Buffer.from(method.I.toBinary(value, this._binaryOptions)), (value) => method.O.fromBinary(value, this._binaryOptions), input, metadata, options);
}
/**
* 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, metadata, options) {
const method = WatchPermissionSetsService.methods[1];
return this.makeServerStreamRequest(`/${WatchPermissionSetsService.typeName}/${method.name}`, (value) => Buffer.from(method.I.toBinary(value, this._binaryOptions)), (value) => method.O.fromBinary(value, this._binaryOptions), input, metadata, options);
}
}
//# sourceMappingURL=watchpermissionsets.grpc-client.js.map