Can this be used for replaying live data offline in the browser?

[thesoftwarephilosopher]

I'm having trouble getting this to work, and I realize it might be because Polly.JS wasn't intended to be used the way I'm using it. So this is more of a question than a bug report or feature request.

Essentially, I'm trying to use Polly.js to help me work offline as if I'm online, by recording my front-end web app's responses while online, and replaying the responses while offline.

In more detail, what I'd like to do is toggle a button in my website's UI where Polly.js will start recording all my front-end web app's outgoing network interactions. Then when I toggle the button again, it goes into replay mode, where instead of going over the network, all my front-end web app's requests are intercepted by Polly.js, and the previously recorded responses for matching requests are used as the intercepted responses.

Is this a use-case Polly.js currently covers?

[thesoftwarephilosopher]

The issue I'm having in more detail is, it seems to be recording just fine to localStorage, as I see a 'pollyjs' entry containing a HAR entry (JSON string). And this for the most part looks like the data I need it to replay when I'm offline. However, when I turn my wifi off and call polly.replay(), and verifying that XMLHttpRequest is still the faked out one, my web app still tries to call over the network, and returns with a network error instead of the recorded response.

[offirgolan]

@sdegutis this is definitely a use-case that Polly attempts to solve and is something we use quite frequently.

Can you share some relevant code snippets here as well as your polly config object?

[thesoftwarephilosopher]

@offirgolan Sure, first near the beginning of my create-react-app (in the initial index.tsx file) I run:

Polly.register(XHRAdapter);
Polly.register(LocalStoragePersister);

I have a button to start recording, which runs:

polly = new Polly('NovaPanelOfflineModeDataThing', {
  adapters: ['xhr'],
  persister: 'local-storage',
});
polly.record();

The button to stop recording and start replaying runs this code:

polly.replay();
// I also experimented with polly.stop(); but it also didn't work

This saves the JSON in local-storage properly, but it never replays responses during replay mode. Instead, in Safari's dev-tools it shows that it's actually making a real network request. When I turn wifi off, that request fails, as it normally would, instead of using the recorded response.

[thesoftwarephilosopher]

I think I might know what's happening... I'm using the AWS JS SDK in the browser, which adds the x-amz-date header to requests, which is always different. If Polly.JS is hashing all the headers to get a unique key to store and lookup responses, it's probably considering them unique every time and never replaying old ones.

[thesoftwarephilosopher]

It looks like my only option here is to set matchRequestsBy.{headers,body} to false, since I can't fine-grain control Polly.js to exclude only certain headers.

[thesoftwarephilosopher]

Whoops, looked like I jumped the gun a bit on this one. Turns out you guys allowed matchRequestBy.headers to be an object or a function, both of which would work just fine for my case. Sorry for the noise.

[offirgolan]

So there is one thing to note here. How the recording/replaying works is that when a new recording comes in, its placed in a "pending" bucket which doesnt get persisted until you call await polly.stop() which calls await polly.persister.persist() under the hood. Only once the new recordings are persisted, are they then accessible to be played back via polly.replay().

In this specific scenario, you would want to call await polly.persister.persist() before polly.replay(). Another way to do this, is to call await polly.stop() when you're done recording a creating a new instance when you want to replay the recorded requests.

[thesoftwarephilosopher]

I only implied it but I tried polly.stop() and it didn't work. I also tried polly.persister.persist() and it wasn't working. I think it's more to do with finding the right combination of matchRequestBy options due to using AWS JS SDK which adds a lot of extra metadata to a request that makes it non-unique.

[thesoftwarephilosopher]

Figured it out: I didn't recognize the order key but it is pretty significant in my case since I want the requests to be replayed regardless of record/replay order.