Closed meop closed 6 years ago
Hi @ijpiantanida hope you will consider this addition of a few new modes.. thank you for the useful project!
Hi @meop, thank you for the PR!
I'll take a deeper look later, but in the meantime can you tell me what's the use case for the fallback
mode? Why target talkback at all?
The use case I have is for development of a data-heavy UI application. It calls a web service with many APIs, but there are a few APIs in particular that are slow to respond, because they aggregate a lot of data every time I navigate to a certain page in the UI.
So when developing the UI application, I will first run it through talkback in record
mode, navigating to the page that will trigger those API calls to get recorded. Then I will stop talkback, delete a few of the records that I do not need pre-recorded, and start talkback again with fallback
mode on, and those heavy APIs stored in tapes.
Now talkback acts a cache for the slow APIs that I purposely recorded, but if I have to navigate around to other parts of the UI application, talkback will still proxy through all the other APIs without issue.
So the mode speeds up development of this data-heavy UI application a lot.
Thanks for the explanation, makes sense.
I did a minor refactor and renamed fallback
to fallbackMode
.
Also release v1.4.0 with the new options included.
Thank you again for the PR! 👍
Adding another couple of use cases:
fallback
mode first requiresrecord
being set to false.. then, instead of throwing an error if the tape does not exist, it would use the source proxy to fetch the live payload.. but it would still notrecord
.. so a hybrid mode between pure recording and pure playbackignoreBody
mode does not look at request bodies when determining a match.. useful for running an app against talkback that is known to make small changes to a POST request every call, like timestamps, but otherwise the rest of the body of the route stays the same, so playback is still useful