FE | Profile | BAI | Feature Toggles (x2)

[SKasimow]

Background

Describe the issue background and scope

Tasks

• [x] Add a double toggle to force a user to have a bad address
• [x] Ask #vsp-idenity about creating a staging user and scrabbling the password after UAT
• [x] investigate using ngrok
• [x] investigate using codespaces

Acceptance Criteria

• [x] Double toggle is in staging
• [x] Team has verified and tested double toggle
• [x] double toggle is in production
• [x] #vsp-identity has given an answer
• [x] A go/no go decision has made for ngrok
• [x] A go/no go decision has made for code spaces

How to configure this issue

• Include practice area in title -- e.g., [Design], [FE], [BE]
• Include project/initiative name - e.g., Auth Profile: Address Change Messaging
• Add label for practice area (frontend, backend, design)
• Add label for project if applicable
• Assign to a Profile team member
• Associate with an Epic if applicable
• If creating for yourself: estimate work if enough info exists to do so

[mdewey]

Summary for ngrok

what is it?

Ngrok allows for tunneling to a local developer machine. The theory is that we can those who want to validate use a developer machine to test new features and such without having to push to staging/production.

results

After spending a day of work on this it looks like it can be done with about a day or so more of work. It does have its limitations. I could not get it to actually work, but there is a path forward on how to get it to work.

I do not recommend this route for UAT, but for internal testing (accessibility, design verification, etc.) this could be good.

good

• The developers have total control over what is shown, so we can develop something quickly, without toggles, and test it out.

limitations

• The test gets a URL like https://2d43-73-40-227-105.ngrok.io/ So it looks weird and untrusting and (at least) in chrome on my machine there are all sorts of warnings being shown to the user that the URL might be dangerous. This is the biggest reason why I cannot fully recommend this for UAT, but for internal testing, it might work.
• The website needs an API to function. We can not use dev or staging. Since we run into CORS errors. This is possible a solution where we stand up a CORS-less server and use a mock server, but that needs to be created. I have a path forward, but I am not sure if it's the right path. It might be after looking at other options.
• It's fully dependent on the machine in front of the developer, so if anything happens to that, the session is killed and needs to be restarted.

[adamwhitlock1]

100% agree with all the Ngrok comments. I messed around with it locally and saw the same things.

As far as the API goes that is definitely the biggest challenge (and will probably be challenging for codespaces as well)

Random ideas that popped into my head:

• running a second Ngrok instance with the api and cors available and pointing to that for the FE ngrok instance
  • auth and other features would need to be mocked, or we just run our mock-api
  • ngrok is only free for one instance I believe so this may not be a viable free solution
  • trying a different service like Tailscale for the api?
  • seems really messy to try and spin up multiple tunnels via multiple services

[mdewey]

Github Codespaces:

After a day of looking into codespaces, it seems to not be working with our infrastructure.

I reached out to the platform team and they also are not sure why it's not working. I don't think this is a good option, yet.

Platform thread: https://dsva.slack.com/archives/CBU0KDSB1/p1654794880712099

TL;DR; Currently not supported.

[mdewey]

Slack thread with VSP-Identity: https://dsva.slack.com/archives/CSFV4QTKN/p1655150178323549