[Web Proxy] Use staging server for Web, Desktop when the "Use staging server" toggle is ON.

[Prince-Mendiratta]

Details

With this PR, we are adding the ability to map all requests to production / staging API depending on the "Use staging server" toggle in user preferences. This change only affects the Development and Staging Environment.

Fixed Issues

$ #12315
PROPOSAL: #12315 (comment)

Tests

.env is not defined

1. Login to ND.
2. Go to Settings > Preferences > toggle the Use staging server toggle ON.
3. Go to Settings > Payments > Add payment Method > Bank Account.
4. Ensure that the Sandbox mode of Plaid is initiated. On Web and Desktop, this can be seen very clearly as the disclaimer is shown at the bottom. For native devices and mWeb, a good way to determine if we are in sandbox or not is the presence of the reCaptcha after selecting the bank institution. If it is present, then we are in production mode. If not, we are in sandbox mode. Another method to determine this on native and mWeb is that the flow redirects to the sandbox URL so it can be seen pretty clearly there as well.
5. Continue to add account normally in sandbox mode with any details. Notice that the account is added successfully after completing the flow.
6. Go to Settings > Preferences > toggle the Use staging server toggle OFF.
7. Go to Settings > Payments > Add payment Method > Bank Account.
8. Ensure that the Production mode of Plaid is initiated. Ways to confirm this are same as mentioned above.
9. Exit out of the production plaid flow
10. Open any chat.
11. Add a new attachment. Upload the attachment. Open it.
12. Ensure all action in step 11 happen seamlessly.

Expected Console Output

Note: There is a known issue in Android where when repeating the above tests will lead to an error. This will be tackled in this github issue.

Note 2: You might see an "Internal React error: Attempted to capture" error while testing but that is being tackled in #13917 and is not related to current changes.

• Verify that no errors appear in the JS console

Offline tests

N/A, doesn't affect the offline functionality, should behave the same as expected behaviour when offline.

QA Steps

This doesn't affect the production behaviour. For staging,

1. Login to ND.
2. Go to Settings > Preferences > toggle the Use staging server toggle ON.
3. Go to Settings > Payments > Add payment Method > Bank Account.
4. Ensure that the Sandbox mode of Plaid is initiated. On Web and Desktop, this can be seen very clearly as the disclaimer is shown at the bottom. For native devices and mWeb, a good way to determine if we are in sandbox or not is the presence of the reCaptcha after selecting the bank institution. If it is present, then we are in production mode. If not, we are in sandbox mode. Another method to determine this on native and mWeb is that the flow redirects to the sandbox URL so it can be seen pretty clearly there as well.
5. Continue to add account normally in sandbox mode with any details. Notice that the account is added successfully after completing the flow.
6. Go to Settings > Preferences > toggle the Use staging server toggle OFF.
7. Go to Settings > Payments > Add payment Method > Bank Account.
8. Ensure that the Production mode of Plaid is initiated. Ways to confirm this are same as mentioned above.
9. Continue to add account normally in sandbox mode with any details. Notice that the account is added successfully after completing the flow.
10. Open any chat.
11. Add a new attachment. Upload the attachment. Open it.
12. Ensure all action in step 11 happen seamlessly.

• Verify that no errors appear in the JS console

PR Author Checklist

• I linked the correct issue in the ### Fixed Issues section above
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the Tests section
  • I added steps for the expected offline behavior in the Offline steps section
  • I added steps for Staging and/or Production testing in the QA steps section
  • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
• I included screenshots or videos for tests on all platforms
• I ran the tests on all platforms & verified they passed on:
  • Android / native
  • Android / Chrome
  • iOS / native
  • iOS / Safari
  • MacOS / Chrome / Safari
  • MacOS / Desktop
• I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
• I followed proper code patterns (see Reviewing the code)
  • I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
    • If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:
  • I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
  • I verified any copy / text that was added to the app is correct English and approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
  • I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
  • I verified the JSDocs style guidelines (in STYLE.md) were followed
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I followed the guidelines as stated in the Review Guidelines
• I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
• I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
• I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
• I verified that if a function's arguments changed that all usages have also been updated correctly
• If a new component is created I verified that:
  • A similar component doesn't exist in the codebase
  • All props are defined accurately and each prop has a /** comment above it */
  • The file is named correctly
  • The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
  • The only data being stored in the state is data necessary for rendering and nothing else
  • For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
  • Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
  • All JSX used for rendering exists in the render method
  • The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
• If any new file was added I verified that:
  • The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
• I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

Screenshots/Videos

without .env defined

Web

web-envless.mp4

Mobile Web - Chrome

android-chrome-envless.mp4

Mobile Web - Safari

ios-safari-envless.mp4

Desktop

desktop-envless.mp4

iOS

ios-envless.mp4

Android

android-envless.mp4

[MelvinBot]

@neil-marcellini @sobitneupane One of you needs to copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

[Prince-Mendiratta]

Requesting a review here from @kidroca @mountiny as well!

[sobitneupane]

Screenshots/Videos

Web

Mobile Web - Chrome

Mobile Web - Safari

Desktop

iOS

Android

[mountiny]

Couple of questions

[sobitneupane]

IF .env is defined,
When UseStagingServer toggle is toggled on, 'STAGING_EXPENSIFY_URL' will be used from .env
When UseStagingServer toggle is toggled off, 'EXPENSIFY_URL' will be used from .env

EXPENSIFY_URL=https://www.expensify.com/
STAGING_EXPENSIFY_URL=https://staging.expensify.com/

@mountiny Will this configuration work for dev api(.com.dev) as well? I won't be able to test on dev api.

[kidroca]

Overall looks good

• not sure whether we need the .env.example change

[neil-marcellini]

If I turn on Use staging server with my dev .env file then all my api requests fail because they are sent to staging. I think we want to still send the requests to expensify.com.dev in that case. I believe that's why we reverted the PR last time.

Screen.Recording.2023-03-23.at.11.59.29.AM.mov

[Prince-Mendiratta]

@neil-marcellini I believe that in this case, if we make the following changes to the .env for internal employees, it should hit the dev domain even when the staging toggle is ON.

EXPENSIFY_URL=https://www.expensify.com.dev/
STAGING_EXPENSIFY_URL=https://www.expensify.com.dev/
STAGING_SECURE_EXPENSIFY_URL=https://secure.expensify.com.dev/

[kidroca]

If I turn on Use staging server with my dev .env file then all my api requests fail because they are sent to staging. I think we want to still send the requests to expensify.com.dev in that case. I believe that's why we reverted the PR last time.

Yeah, my last comment is about that: #16432 (comment)

So basically the toggle would do nothing for you - it won't change the API
In that case could you consider:

• internal devs don't use the toggle (it's only about external devs that want to use fake bank accounts)
• hide the toggle in DEV when the developer is not using a PROXY server

[neil-marcellini]

@Prince-Mendiratta Yeah but I think the point is we don't want to ask all internal engineers to make that change if we can avoid it.

[Prince-Mendiratta]

Another possibility that opens up is that we can match if the EXPENSIFY_URL ends with .dev or uses ngrok, we can hide/disable the Use Staging Server toggle altogether. What do you think?

[kidroca]

Question:
Is there an existing way internal developers are using the staging api?

I think you'd be changing some ngrok setting and you won't really use the toggle

[neil-marcellini]

Question:
Is there an existing way internal developers are using the staging api?

We make a backup of our .env file and then rename .env.staging to .env. Then we run the app on a native platform to get around CORS errors.

I'm fine with hiding the "use staging server" toggle when using internal development environment.

[Prince-Mendiratta]

@neil-marcellini @kidroca @sobitneupane updated, please have a look!

[kidroca]

✅ LGTM!

[mountiny]

Is there an existing way internal developers are using the staging api?
I think you'd be changing some ngrok setting and you won't really use the toggle

Yep, I just comment out the internal vm .env and add the staging one

[mountiny]

@Prince-Mendiratta Left one comment

[Prince-Mendiratta]

To conclude and summarise the changes that this PR introduces, we should define the environments, platforms and the actors.

Actor 1: External Developer. (Contributor)
Actor 2: Internal Developer. (Internal Employee)
Actor 3: QA team.

Environment 1: DEV. (Contributor)
Environment 2: Internal DEV. (Internal Employee) (using .dev domain or ngrok`)
Environment 3: Staging.
Environment 4: Production.

Platform 1: Web
Platform 2: mWeb
Platform 3: Desktop
Platform 4: Native

Now, the "Use staging toggle" is available only for Actor 1 and Actor 3 on Env 1 and 3, for all platforms.

For Web, there are 2 ways to run the app:

1. Using a web proxy. This is the option used by contributors. It routes the requests to a proxy server and depending on the toggle status, sends the request to the respective API endpoint. No .env changes are required.
2. Without the web proxy, directly sending the requests to the endpoint. This is done by internal employees. They do not make use of the staging server toggle and the use internal .dev domain for running the app. To use staging environment, direct .env changes are made.

For native apps,
They are built using the .env defined. If no env file is defined, it'll fall back to the default values, where the staging server toggle is working since native apps send requests directly to the endpoints.

For desktop, no proxy is used and the requests are sent directly to the endpoints.

So now, no changes need to be made anywhere to the .env file and it'll automatically respect the configuration of the staging server toggle.

[mountiny]

@Prince-Mendiratta Great comprehensive write-up, thank you very much 🙇

[Prince-Mendiratta]

Since the contents of the .env files do not affect the host anymore, we do not need tests with .env defined since they'll have the same behaviour. Updated tests accordingly.

[mountiny]

Thanks for working on this!

[Prince-Mendiratta]

Hi @neil-marcellini and all. Hope you guys had a great weekend. I think today can be the D-Day for this issue, can you please review it?

[mountiny]

@Prince-Mendiratta great job indeed. I think @neil-marcellini should be able to finish this one today!

[neil-marcellini]

Yes I will take a look soon!

[sobitneupane]

@mountiny What's your thought on this?

[neil-marcellini]

Ok I think this is good to go. Thank you.

[neil-marcellini]

@sobitneupane all you for the reviewer checklist.

[sobitneupane]

Reviewer Checklist

• I have verified the author checklist is complete (all boxes are checked off).
• I verified the correct issue is linked in the ### Fixed Issues section above
• I verified testing steps are clear and they cover the changes made in this PR
  • I verified the steps for local testing are in the Tests section
  • I verified the steps for Staging and/or Production testing are in the QA steps section
  • I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
• I checked that screenshots or videos are included for tests on all platforms
• I included screenshots or videos for tests on all platforms
• I verified tests pass on all platforms & I tested again on:
  • Android / native
  • Android / Chrome
  • iOS / native
  • iOS / Safari
  • MacOS / Chrome / Safari
  • MacOS / Desktop
• If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
• I verified proper code patterns were followed (see Reviewing the code)
  • I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
  • I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
  • I verified any copy / text that was added to the app is correct English and approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
  • I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
  • I verified the JSDocs style guidelines (in STYLE.md) were followed
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I verified that this PR follows the guidelines as stated in the Review Guidelines
• I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
• I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
• I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
• If a new component is created I verified that:
  • A similar component doesn't exist in the codebase
  • All props are defined accurately and each prop has a /** comment above it */
  • The file is named correctly
  • The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
  • The only data being stored in the state is data necessary for rendering and nothing else
  • For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
  • Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
  • All JSX used for rendering exists in the render method
  • The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
• If any new file was added I verified that:
  • The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
• I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

[OSBotify]

✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

[OSBotify]

🚀 Deployed to staging by https://github.com/neil-marcellini in version: 1.2.91-0 🚀

platform	result
🤖 android 🤖	success ✅
🖥 desktop 🖥	success ✅
🍎 iOS 🍎	success ✅
🕸 web 🕸	success ✅

[OSBotify]

🚀 Deployed to production by https://github.com/luacmartins in version: 1.2.91-1 🚀

platform	result
🤖 android 🤖	success ✅
🖥 desktop 🖥	success ✅
🍎 iOS 🍎	success ✅
🕸 web 🕸	success ✅