In my previous organisation, where I worked as a backend engineer, during development of any feature or even a small bug fix, we used to first develop & test the changes on the locally setup MicroService. After that, we deploy the changes on the Kubernetes stage cluster in an isolated namespace, which has all the other services deployed too. The deployment pipeline usually took around 5–10mins to completely deploy all the services. After the stage is setup, we change the API gateway in our debug app to point to the stage environment so we can test the changes end-to-end on the app.
This often requires multiple cycles and sometimes unstable stage environment makes the entire development & testing very frustrating. We often found ourselves fixing the configuration on stage environment and then testing the changes. This is how the process looked like before:
- It was very time consuming.
- Multiple deployments required after every change/commit.
- Debugging using breakpoints in IDE was not possible.
- Maintaining a stage environment is very hard. Our Staging environment lacked a lot of data, stability issues so every-time testing on stage was pain.
Almost every developer uses this tedious process to test out the changes. As this process is time consuming, sometimes we miss certain edge cases, as a result multiple times it had also led to downtimes 😢 and bugs in production.
We tried telepresence too for local testing , but no one ended up using it due to the tedious process in setting it up.
Requestly is a cross-platform developer tool to intercept all local network traffic and gives request level granular control to modify individual pieces of an API request. Requestly can be leveraged here to reduce the development & testing time and also testing different corner cases.
Using Requestly desktop app, you can intercept all traffic from your Android & IOS debug apps. Then you can create a traffic modification rule (simply rule) to redirect a particular endpoint/service to your local machine and not to production endpoint (A No-Code solution for the Coders) This lets users instantly test out any changes directly against production environment without depending on the staging environment.
On top of this, you can instantly test out how the app reacts when the response of an API changes, without making any changes to the code. You can mock API responses using Requestly. You can also test for 4xx, 5xx scenarios, add artificial latency to your APIs and test your app.
So this is how the process looks like now:
For example, If you are working on Search service and want to test Type To Search experience, this setup can be really life saviour. For this you can configure a Replace Rule in Requestly like this
Replace: https://api2.grofers.com/v5/search With: [http://localhost:5000/v5/search](http://localhost:5000/v5/search)
Here’s how the flow of data look like —
- Changes instantly reflected on app
- No multiple deployments cycle required.
- Test different edge cases which only exist on production. Deploy on production with confidence.
- Debugging with breakpoints in your favourite IDE is now possible
- Minimize dependency on Stage environment
Now you know the benefits of using Requestly in your local API development & testing. It’s time to set up Requestly. Here’s step by step guide.
Go to https://requestly.io/desktop and download the desktop app for your OS — Mac, Linux & Windows.
At this point, you should be able to see the traffic from your debug app in the Network Traffic table.
Redirecting v5/search endpoint from Production to local server
Click on Create New Rule and then Select Modify Headers to add additional headers to the request which Kong adds in the production environment So that your localhost end point also receive the same headers.
That’s it! You should be able to test features like TypeToSearch directly in debug app against the production K8s cluster utilising the production data on ElasticSearch and other production configurations.
Please note we don’t intend to discourage testing in the stage environment. We just want to emphazise that you can avoid multiple cycles of deployment on stage during the development. Ofcourse, the ideal practice should to test end to end on local, then doing testing on stage and then deployment on production.
Happy testing! By Sahil Gupta
Originally published at https://requestly.io.