Behind all 'environments' lies a tech team's blood, sweat and tears. It’s probably something on which they have spent time anywhere between less than a day to infinite time, coding. As a front-end engineer, I know how easy it is to mess up handling and maintaining these environments. We’re always one force push away from releasing something in production and sometimes that distance is covered by an existing bug in production.

The standard way to maintain these environments is to create a .env file, which is always stored locally. As you know, if these secrets leak, the world will crumble, we’ll lose all harmony, and humanity as we know it will perish. This statement might be an exaggeration, but you do become an easy potential target for hackers. So, we stick to the standard way of managing these secrets with our lives and devices.

How should you use these environment variables?

These environment variables serve different purposes depending on which part of the feature you are working on. For a backend engineer, these could hold credentials like keys and secrets of services and databases, i.e. the connection between them. For front-end engineers, it could be a place to store authentication tokens, base URLs for APIs, etc.

As a front-end engineer, if anything breaks in any of these environments, I’ll go back to the .env file to change the API URL, token, etc.

Once done, I start working on the different problem statements without changing these env variables. For the sake of simplicity, let’s assume that we have a product to check out on e-commerce sites. In this product, we now want to add an edit button for all existing addresses, much like on the food delivery apps we’re so used to.

For this feature addition, changes required are:

• An ‘edit’ button next to the current address.
• A dropdown with an input field that opens when you click the button.
• A save address button to save changes.

Implementing the changes uniformly - An example

The respective engineer(s) work on a tech spec to decide the implementation of the feature based on the need. The high-level decisions for our feature implementation through the tech spec are:

• What should the GET API endpoint be to fetch all addresses
• What should the UPDATE API look like?
• What is the endpoint?
• What would the schema of the body be?
• Will we need to pass any more parameters apart from the body?
• What are the required fields in the form?

After discussing and scoping out the feature in this manner, we begin implementing it. For our example, I would need to make changes to the UI and a backend engineer would need to build the APIs. Given that both things will run in parallel until APIs are made, I will end up mocking them.

After building APIs, the backend engineer will deploy them in the development environment. After that, I will remove mocks of API and integrate the APIs deployed on development. While this new feature is being developed, QA reported a bug in a different part of the checkout.

To fix the issue, I’ll create a new branch from the main and change the API environment to production to reproduce the issue. Once I am able to produce it in a production environment, I’ll fix the issue on this remote branch. Then test it and push it straight to production (given the critical nature of the bug). Now, I can go back to finishing the new feature!

I switch branches back, finish developing the feature and put it on dev. The development bugs are fixed. In the staging environment, QA raises a few issues, they’re fixed and QA gives a pass.

Wow, the moment of truth, but wait, there’s a merge conflict on main.

How? Nothing changed, or did it?

I’ll take a pull from the main branch, look at the changes, trace back to the time I made the changes, and fix the merge conflict in my branch. I’ll also update both the dev and staging environments by pulling from the main.

I’ll then push my new fix to dev, and test it locally and in dev. Post that, deployment on staging will be in progress, and pass QA. Finally, I can merge the new feature in peace. Sounds familiar? An extra cycle of testing, fixing and deployment happened just because I forgot to take a pull from the main.

What is Requestly and how we use it

At Bureau, we avoid such mistakes and make tests more streamlined using Requestly. It is a lightweight proxy available as a browser extension and desktop app to intercept and modify network requests. With Requestly, you can mock API responses, modify headers, redirect Url, delay/throttle requests, etc.

We use the URL redirection feature for testing, switching resources (APIs/scripts) between environments and fixing bugs. It allows us to change some part of the URL or the entirety of it on runtime. For example, we have the following base URLs for the API

Dev environment: `https://api.checkout.dev.bureau.id`

Staging: `https://api.checkout.stg.bureau.id`

Production: `https://api.checkout.prd.bureau.id`

Using Requestly, I can create a rule in 4 steps without worrying about toggling between environments

After creating a rule, you can pin the ones you’ll use the most to be easily available by clicking the extension. You toggle the switch on for changing URL, and voilà. In our case, when QA raises a bug, if I had an environment setup already in Requestly, I wouldn’t have had to change the environment to push the fix. I could’ve had more sanity while switching back because the changes are platform agnostic. I would’ve possibly not run into the roadblocks I experienced earlier. Hence, a tool like this helps in improving a developer’s productivity.

Our QA team uses Requestly, so they don’t have to run the code on their end to test different environments. They use the tool to change the URL and determine settings in which the bug is reproducible.

All-in-all, this tool is a must-have in a productive developer’s arsenal mainly because it helps to develop and test more efficiently.

At Bureau, the brightest tech minds in fraud prevention are sharing their hard-earned insights,  
revealing the best-kept secrets of the trade. It’s all about making life easier for fraud fighters everywhere. You can also explore Bureau's documentation here.

‍

Schedule a consultation with the Bureau team here.

‍