New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sourcegraph LaunchDarkly extension design #1249

Open
yevbar opened this Issue Dec 6, 2018 · 8 comments

Comments

Projects
None yet
6 participants
@yevbar
Copy link
Contributor

yevbar commented Dec 6, 2018

Feature request description

Sourcegraph LaunchDarkly extension

Is your feature request related to a problem? If so, please describe.

The Sourcegraph browser extension allows for individuals to create their own extensions - see Authoring docs. There is currently one for Codecov and there isn't one for LaunchDarkly (yet!)

Describe alternatives you've considered.

  1. First feature: Get information on feature flag on hover (visibility check requires client id)

image

Every flag has its own page that looks like https://app.launchdarkly.com/default/LOCATION/features/FLAGNAME/targeting so a link to this page could be included in the hover box.

Visibility of an LD feature requires a client id which can be obtained similarly to the Codecov extension

image

  1. Second feature: Listen for changes in feature flags (client id required)

image

Additional context

This is posted to gather feedback on what should/shouldn't be implemented. The above features are what are provided in the JavaScript SDK. There's one more functionality provided which is the manipulation of the user object used to connect to LD however it makes no sense to store Github viewing session in the sessions database.

@yevbar

This comment has been minimized.

Copy link
Contributor Author

yevbar commented Dec 6, 2018

As clarification: I plan on developing this extension, I'm putting this issue here so I could show what features are currently planned and see what else needs to be added

@sqs

This comment has been minimized.

Copy link
Member

sqs commented Dec 6, 2018

Awesome!

For the first feature (seeing whether a feature flag is visible), here are a few related improvements that I think are more valuable than listening for changes in feature flags:

  1. Showing the visibility info in an after-line decoration like the blame text (Ying Li, 2 years ago: ... in https://sourcegraph.com/extensions/sourcegraph/git-extras), using setDecorations in the Sourcegraph extension API
  2. Showing other stats beyond just visible yes/no: # of users for whom this is visible, when the targeting of this feature flag was last changed and by whom, and any SVG charts or other visualizations that might be available (the SVG charts would be shown in a hover, not an after-line decoration)
  3. A panel (using createPanelView in the extension API) that shows all of the feature flag keys that are used in the repository and links to a search query for each one that shows all of the places where that feature flag key is used. The panel would just consist of a Markdown-formatted list with links. Bonus for including those same stats as in (2) here, too!

@sqs sqs added the extensions label Dec 6, 2018

@sqs sqs added this to the 3.0 milestone Dec 6, 2018

@atrakh

This comment has been minimized.

Copy link

atrakh commented Dec 7, 2018

Hi @yevbar,

I'm Arnold, I work at LaunchDarkly, and I built our Visual Studio Code extension, which has similar functionality to your extension proposal. We think this is a great idea!

I'm not too familiar with creating extensions for Sourcegraph, but I have some ideas for how we could make the @sqs's suggestion of displaying flag stats in sourcegraph possible. This functionality wouldn't work too well with the JavaScript SDK, because the JS SDK doesn't store any feature flag configuration data internally, but instead delegates to the LaunchDarkly API to handle flag evaluations. This is done to avoid exposing feature flag configurations in client-side contexts.

On the other hand, our node sdk does store flag configs in-memory, which will make it much easier to access flag settings (number of user targets, rules, etc). For our VSCode extension, we were able to retrieve and interact with flag configs using the node SDK's internals (see https://github.com/launchdarkly/ld-vscode/blob/master/src/flags.ts#L100).

Also had a question about your planned implementation- will the extension resolve all string literals containing flag keys, or only when they're inside of variation calls?

Hope the above is helpful! Feel free to @ me with any questions

@ryan-blunden

This comment has been minimized.

Copy link
Contributor

ryan-blunden commented Dec 10, 2018

@yevbar This sounds brilliant! If there is anything I can do to help, let me know.

@atrakh The Sourcegraph extension API is similar to VSCode's and with some tweaks (e.g. higher level of abstraction for showing messages and notifications) you could create an extension that re-uses most of the code in flags.ts and configuration.ts. I'd be happy to help you port it and answer questions.

@chrismwendt

This comment has been minimized.

Copy link
Contributor

chrismwendt commented Dec 13, 2018

Here's the API for fetching feature flag info: https://apidocs.launchdarkly.com/docs/get-feature-flag

Here's an example project that uses LaunchDarkly https://github.com/launchdarkly/hello-node/blob/master/index.js

@yevbar

This comment has been minimized.

Copy link
Contributor Author

yevbar commented Dec 13, 2018

@atrakh

Hey again, we were wondering if we could use the V1.0 API since the request is much simpler (just /features/:key)?

@atrakh

This comment has been minimized.

Copy link

atrakh commented Dec 13, 2018

Hey again, we were wondering if we could use the V1.0 API since the request is much simpler (just /features/:key)?

The v1 REST API has been deprecated, and is not compatible with most LaunchDarkly accounts.

If you're planning on using our API over an SDK to retrieve flag data, I'd recommend using the v2 API's flags endpoint. The main difference between the v1 and v2 APIs is that in v2, flags are scoped to projects, and results can be filtered by environment (since your environments, like production and staging, can have different flag rules). So, it's likely that the extension would need to either iterate over all projects, using the projects endpoint, or have the user configure which project they'd like to use at extension installation/configuration time.

@yevbar

This comment has been minimized.

Copy link
Contributor Author

yevbar commented Dec 13, 2018

@atrakh Ok, I'll be iterating over all the user's projects and features then 🙂

@nicksnyder nicksnyder modified the milestones: 3.0-preview.2, 3.0 Dec 14, 2018

@sqs sqs modified the milestones: 3.0, 3.1 Dec 31, 2018

@sqs sqs modified the milestones: 3.1, Backlog Jan 30, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment