NoamGaash / playwright-advanced-har

MIT License
26 stars 0 forks source link

Intercepting requests to influence HAR lookups, or conditionally enriching responses #19

Closed shuckster closed 3 months ago

shuckster commented 5 months ago

First of all, thank you for this library.

The API I'm trying to mock has the following behaviour:

  1. An initial POST to the BE passes generated tempIds for each entity
  2. The BE accepts the tempIds and echos them back in the response
  3. The BE also echos back fixedIds at the same time, and on subsequent responses
  4. The BE will NOT echo back tempIds on subsequent responses

I wouldn't be asking here if the solution was as easy as creating deterministic tempIds in the FE, which would almost certainly solve my issue, but I'm trying the following approaches.

Given:

stateDiagram-v2
direction LR

FE --> request
request --> HAR
HAR --> response
response --> FE

I want to try and perform the following intercepts for my HARs:

stateDiagram-v2
direction LR

FE --> request
request --> INTERCEPT_req
INTERCEPT_req --> HAR
HAR --> response
response --> INTERCEPT_res
INTERCEPT_res --> FE

Essentially I want to either:

  1. Use INTERCEPT_req to rewrite the tempIds and make them deterministic so that future HAR playback will pick up the right stored mocks
  2. Configure playwright-advanced-har to exclude all tempIds during recording, but use INTERCEPT_req to conditionally enrich INTERCEPT_res with the tempIds the FE sends

Hope this is reasonably clear, and thanks in advance for any advice!

NoamGaash commented 5 months ago

Hi @shuckster, let me see if I understood your problem:

  1. You want to let the client send a different tempId when making the POST request
  2. you want the map the new tempId to the recorded tempId in the response, and in all future requests and responses.

Both approaches you introduces sounds valid to me, but I believe that the HAR file will save the original requests (and will not take into consideration the changes you made to the data).

I think a nice approach for this problem could be abusing the postDataComparator to store the tempId once any request is having that field, and save both clientTempId and backendTempId (when update: flase, both values will be different). then, I would use postDataComparator and postProcess to replace the new ID to the old one from the recording whenever it appears on any request / response.

What do you think?

Thanks for being an early-adopter of this library, your feedback is highly appreciated :1st_place_medal:

NoamGaash commented 3 months ago

please re-open this issue if you have any further thoughts

shuckster commented 3 months ago

Gosh, has it really been so long? Apologies for missing your message.

We're still using your project and managed to get around the issue above by having our ID generators be "seeded", and we would have hard-coded seeds for our tests.

Your project has been extremely useful and I'll certainly be in touch if something else comes up, so thank you again for your work.

NoamGaash commented 3 months ago

That's so great to hear! Thank you for your feedback, keep updating! :)