Update data source for getSuggestedFollowsByActor

[estrattonbailey]

We've added a new parameter to our otherwise generic app.bsky.unspecced.getSuggestionsSkeleton called relativeToDid, which requests suggestions relative to that DID instead of that of the viewer. The intent here is to unify the algorithm we use to suggest follows to the viewer by replacing the algo that powers getSuggestedFollowsByActor with the one we use for our other suggestions in the app.

I've integrated this unspecced endpoint and new param into the existing endpoint and put it behind a feature flag so we can selectively turn it on to test.

To do so, this PR also integrates StatSig. I've added a mgmt class FeatureGates that lives on AppContext and integrates with the start and destroy lifecycle of the app's context.

It can be used within route handlers like this:

const gates = ctx.featureGates

if (gates.check(
  await gates.user({ did: '...' }),
  gates.ids.MyGateId
)) {
  // gate enabled, do something
}

In testing, StatSig is put into "local mode", which allows you to override flags for testing. See here for more info.

[devinivy]

Lookin good, just left a few notes! The main ones are a. lifecycle of statsig, b. failing open when statsig is failing or not configured at all. I think they both could be addressed and brought into a common pattern used in the node services by making a new class for managing feature gates, which will live on the AppContext and used as part of the AppContext's lifecycle. Maybe could look roughly like this:

interface FeatureGates {
  private statsig: StatsigInstance | undefined
  constructor(config: StatsigConfig | undefined)
  // when statsig is being used, initializes statsig. called in AppContext's start().
  start(): Promise<void>
  // when statsig is being used, shuts-down statsig. called in AppContext's destroy().
  destroy(): Promise<void>
  // when statsig is being used returns statsig's gate, otherwise fails open with a log and returning the default.
  // when statsig is not being used returns a default for the gate (probably false).
  check(gate: Gate, userId: string): boolean
  getUserId(did: string): Promise<string>
}

[devinivy]

Clean!! Just a few tiiiny tweaks and I think we'll be rockin.

[devinivy]

I think we'll want to move this up to before the server is listening / fielding requests.

[devinivy]

We should at minimum log the error so we can see there's an issue—you'll find some loggers in ./logger and we can add a new one if we want!

[devinivy]

Would it be possible to hoist this behavior up either to config.ts or even the appview's statsig config in the tests? This isn't a major deal / can totally punt for now and just leave a note if it's a pain! The reason we've been trying to do things that way is just to avoid behaviors that don't flow from the app entrypoint/config, and perhaps a sprinkle of brain being a little wired to certain 12 factor thinking 🤣 .

[devinivy]

Ace!