feat(rc): Add server side Remote Config support #2529
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Define SSRC API --------- Co-authored-by: Xin Wei <trekforever@users.noreply.github.com>
Add API changes needed for SSRC --------- Co-authored-by: Xin Wei <xinwei@google.com> Co-authored-by: jen_h <harveyjen@google.com>
Add public SSRC methods --------- Co-authored-by: Xin Wei <xinwei@google.com> Co-authored-by: jen_h <harveyjen@google.com>
We have a Firebase AIP to avoid these prefixes.
…ith defaults. (#2503) In the logic where we backfill config with defaults, the first argument to Object.assign should be an object to assign to, but the code passed the object containing the defaults.
In practice, we only set default config using the initialization methods, so make the internal field private to simplify the API.
* Get And condition passing * Support and.or condition * Support true condition * Support false condition, and fix tests * Use or.and, not the other way around * Integrate conditional values into evaluate method * Test handling for multiple conditions * Clean up logs * Extract condition evaluation to class for testing * Namespace condition names * Iterate over ordered condition list * Test condition ordering * Differentiate named conditions * Document condition types * Generalize condition eval test and fix styling * Replace log statement with todo * Implement evaluate percent condition for RC server-side * Apply lint fixes * Add context param to evaluate method * Add tests for percent condition eval * Update evaluator tests to use context * Increase threshold to +/- 500 for percent condition eval tests to prevent some flaky tests. * Clean up percentCondition tests a bit and add note on the tolerance used * Apply suggestions from code review Co-authored-by: jen_h <harveyjen@google.com> * Update copyright date and remove stray log statement * Mock farmhash in tests * Add Math.abs for farmhash - to be consistent with the internal implementation * Regenerate package-lock to fix Node 14 CI error re busboy * Fix lint errors * Rename "id" to "randomizationId" per discussion * Extract API * Only return false in cases of uknown template evaluation * Remove product prefix from type names * Remove product prefix from exported types * Remove unused "expression" field from server condition * Extract API * Remove prefix from impl classes, for consistency * Remove prefix from new internal classes * Remove "server" prefix * Remove prefix from NamedCondition * Rename "or" and "and" fields to match API * Rename "operator" field to "percentOperator" to match API * Extract API after "and" and "or" rename * use longjs library for hash * re-run npm install * re-attempt * use node 14, re-attempt * remove file * Add comment, switch from lte to lt --------- Co-authored-by: Erik Eldridge <erikeldridge@google.com> Co-authored-by: Xin Wei <xinwei@google.com> Co-authored-by: jen_h <harveyjen@google.com>
…a RC server template (#2520) * Add support to pass in a json string for RC server template initialization * Merge ssrc changes * Apply lint changes * Update comments * Run api-extractor:local * Update comments and address feedback * Update inline comment and lint fixes * Revert toJSON functionality for ServerTemplate
RC's existing SDKs define type-specific getters, like getBoolean. These aren't idiomatic for TS/JS, but have a couple advantages: 1. RC param names, values and types are mutable remotely, so a simple object can’t guarantee a strict type for application logic. A formal schema would address this, but feels excessive for the common case. Type-specific methods are consistent with RC's current SDKs and ensure appropriate types for application logic. 2. RC Android and iOS SDKs log events when personalized values are used. A method interface facilitates such additional functionality
* Add #set on ServerTemplate to allow for setting and caching a server template * Simplify initServerTemplate to make use of the new setter * Update tests * Address comments and feedback * Update API docs * Add export for new type ServerTemplateDataType to index.ts * Update some inline comments
trekforever
approved these changes
Apr 10, 2024
There was a problem hiding this comment.
nit: since we have a new internal folder now (currently only containing value-impl.ts), would we want to move this file into there and rename it to just condition-evaluator.ts?
There was a problem hiding this comment.
We can, but I think we can safely do that in a follow-up change, since it's internal.
I also just noticed that we use the @internal annotation on the RemoteConfig constructor, which makes me wonder if the convention should just be that. Anything with the annotation is internal, regardless of the file's name or location. We could then remove the "internal" directory and file name suffixes.
| public readonly etag: string; | ||
| public version?: Version; | ||
|
|
||
| constructor(template: ServerTemplateData) { |
There was a problem hiding this comment.
nit: template can be readonly too?
There was a problem hiding this comment.
That'd make sense, but I'm unsure it's worth another PR. The current approach is comparable to the existing RemoteConfigTemplateImpl constructor.
Aside, this reminds me of java's final. Most things are readonly, but applying a modifier to each variable ends up being more trouble than it's worth. A single designation, like const, is better.
lahirumaramba
approved these changes
Apr 12, 2024
lahirumaramba
changed the title
This was referenced May 18, 2024
This was referenced Sep 7, 2024
This was referenced Sep 13, 2024
This was referenced Sep 27, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Discussion
We've been merging SSRC changes into the
ssrcintegration branch. This PR mergesssrcintomaster.Testing
Unit tested by running
npm test.Functionally tested by installing the Admin SDK in a test server using this branch.
API Changes
Incrementally reviewed via ssrc-prefixed feature branches.