search

opendiffy / diffy

Other
1.25k stars 142 forks source link

Supporting different URL parameters between Master and Feature branch #57

Closed suryakant261 closed 2 years ago

suryakant261 commented 3 years ago

Our use case was that new features/changes are released behind a flag and that flag is enabled/disabled via a URL parameter. So URL parameter of master branch and feature branch could be different. Adding support for that in the diffy code.

suryakant261 commented 3 years ago

@puneetkhanduri Please review this

suryakant261 commented 3 years ago

Thanks for your contribution. Could you please add some comment in the readme clarifying what assumptions are being made about the incoming request urls. i.e. Could the proxied requests contain their own api roots that need to be replaced? Adding an api root to the end of an existing uri will not work for all use cases (specially those involving path params).

Lastly, please confirm if this request is being made for a use case at Flipkart. Please share some details about the use case.

Hi @puneetkhanduri ,

Thanks for reviewing this. There are a couple of use cases for which we wanted to add support in the diffy. Adding details and examples below.

  1. During API endpoint migration/ version upgrade

Let's say master's endpoint is https:ip1:port/api/v4/ and candidates' endpoint is https:ip2:port/api/v5/. The current diffy restricts to use same path for both master and candidate and since paths are different between master and candidate in this example, regression test is not supported

  1. A feature behind a flag

Let's say master's endpoint is https:ip1:port/api/v4?DB=prod and candidates' endpoint is https:ip2:port/api/v4?DB=newDB. We have a query param ,DB in this case, which translates inside the application code to point to which DB the application should talk to. Now this kind of regression test is not supported too.

At flipkart, we have tried to use diffy for Autosuggest service (More about autosuggest : https://tech.flipkart.com/building-personalized-autosuggestion-9e705d5bf5f8). Most of  our regression tests require support for point number 2.

As a solution for this, we have added extra parameters of apiroot which solves for both use cases 1 and 2. But as you rightly pointed out this will lead to issues when the user sends requests with path parameters/query parameter to the proxy server as well as have used apiroots while starting diffy server. Is it sufficient to add in the documentation that we shouldn't use at both places together ( either set path parameters in apiroot OR send path parameters through proxied request). Or would you suggest any other approach to enable point 1 and 2.