Implemented the listRulesetMetadata() API #622
Conversation
| @@ -119,6 +124,38 @@ export class SecurityRulesApiClient { | |||
| }); | |||
| } | |||
|
|
|||
| public listRulesets(pageSize: number = 100, pageToken?: string): Promise<ListRulesetsResponse> { | |||
There was a problem hiding this comment.
do you even want to allow users to customize this number?
There was a problem hiding this comment.
I see your point. This was approved during the API review process on the grounds that other similar APIs in the admin SDK (e.g. auth.listUsers()) allow setting custom page sizes. So we are being consistent here. But I agree. Most users won't need it.
| url: `${this.url}/rulesets`, | ||
| data, | ||
| }; | ||
| return this.sendRequest<ListRulesetsResponse>(request); |
There was a problem hiding this comment.
consider providing a convenience method that repeatedly paginates until the end and then returns the entire list
There was a problem hiding this comment.
We haven't really done that sort of thing in Node.js before. But that's something we can certainly consider in the future.
I think we haven't done this for APIs like auth.listUsers(), since a project can potentially have millions of users, and we don't want an implementation that buffers all that data in memory. But since there's a hard limit on how many rulesets a project can have, it is probably not a bad idea here.
In some of the other languages like Java and Python we already have established iterable/iterator patterns to support this use case cleanly. e.g. https://firebase.google.com/docs/reference/admin/java/reference/com/google/firebase/auth/ListUsersPage.html
* Implementing the Firebase Security Rules API (#604) * Implementing the Firebase Security Rules API * More argument validation and assertions * Cleaning up the rules impl * Internal API renamed * Fixing a typo in a comment * Implemented createRulesFileFromSource() and createRuleset() APIs (#607) * Implementing the Firebase Security Rules API * More argument validation and assertions * Adding the rest of the CRUD operations for rulesets * Cleaning up the rules impl * Cleaned up tests * Adding some missing comments * Removing support for multiple rules files in create() * Implemented the deleteRuleset() API (#609) * Added deleteRuleset API * Merged with source * Implemented the API for releasing rulesets (#610) * Implemented the API for releasing rulesets * Removed createRelease logic * Updated comment * Added the getStorageRuleset() API (#613) * Implemented the API for releasing rulesets * Removed createRelease logic * Added getStorageRules() API * Removed some redundant tests * Implementing the remaining releaseRuleset APIs (#616) * Implemented the listRulesetMetadata() API (#622) * Adding the rules API to the public API surface (#625) * Added rules API to the public admin namespace * Updated docs * Addressing comments regarding the d.ts file * Updated App typings * Rules integration tests (#633) * Rules integration tests * Refactored by adding some helper methods * Cleaned up some conditionals * Added verification for deleteRuleset test * Renamed tempRulesets * Handling ruleset limit exceeded error (#636) * Fixing alignment of an annotation * Updated comments
listRulesetMetadata()method with support for paging through rulesets.RulesetMetadataListinterface to represent the return value.This completes the implementation of the
security-rulesmodule. Once this is done, we will need a couple more PRs to get this hooked up to theadminnamespace and implement the integration tests.