Freigeben über

Building VSTS Extensions with feature flags – Part 3

  • Artikel

We shared possible scenarios for using feature flags in part 1 of our research. Part 2 focused on securing data sent to LaunchDarkly using the Azure Function. We continue with the call of the LaunchDarkly Rest API from VSTS extensions.

You may recall, that we intentionally deferred the scenario in which the user decides which feature to opt-in or opt-out of in previous posts.

To implement this scenario, we need to call the LaunchDarkly Rest API. For security reasons the SDK does not support this feature. It’s not permitted to make a call to an external API from within the VSTS extension. Any such request would fail with a CORS error. We also must secure the call to the API to prevent a malicious user spoofing calls on behalf of another user and make unexpected feature flag configuration changes.

To address this problem, we use another Azure Function which isn’t blocked by VSTS. It will act as “proxy” between the VSTS extension and LaunchDarkly, responsible for the security of the endpoint and making the LaunchDarkly Rest API call.

Here’s a possible flow:

  1. The VSTS extension calls an Azure Function, passing the token of the current user and the feature flag information.
  2. The Azure function:
    • Check token validity and construct the userkey
    • Call the LaunchDarkly Rest API to update the feature flag of the userkey
    • Return the result from the Rest API to the VSTS extension
  3. The VSTS extension adapts its user interface and behavior according to the response

Azure Function sample code

Focus on lines 20 and 23-25:

The azure Function checks the token with the checkTokenvalidity method, the same way as in the GetHashKey Azure Function (see Part 2), and calls the UpdateUserFlag internal method to call the LaunchDarkly Rest API:

As the VSTS extension receives the response from the Azure Function, it adapts its UI and behavior by activating or deactivating the feature to the user.

Sample of code of the extension that processes the UI change

So, we’ve covered all scenarios and have completed our research. In the next post in this series, we’ll share the outcomes of implementing these scenarios in our extensions.

Feel free to give us your feedback on this series of blog post as well as ideas of features on our extensions.