Capturing data for later use
One of the main problems that Spike solves is the downtime that results when a backend service suddenly dies, leaving you with no workable data to develop and test against. Spike has several ways of helping with this problem. Here we describe data Capturing and Playback and Rewind modes.
Capturing and Playback modes
When in "Capturing" mode, Spike stores responses it receives from every backend service. Later on, if a service goes down, then Spike can be put into "Playback" mode. During playback, if your application makes any request whose URL exactly matches one it saw during Capture, then Spike will immediately respond with the stored data response. The backend service will never be invoked.
You can find the list of service responses that Spike has captured, and toggle between Capturing and Playback modes, in the Capture tab in the Spike UI header.
Data capture and playback is useful if during development or testing, you frequently hit the same backend services repeatedly, with no change on your end. For example, you may be tweaking a new UI feature, and are editing CSS and reloading a webpage over and over again. In that case, it's completely redundant to be hitting the live backend anew with every refresh, and Spike can short-circuit that process and both speed up your work, and protect you against backend downtime.
Data capture and playback works based on the request's URL. It does not look at headers or at the request body (in case JSON or a form POST is being sent, e.g.). Because the matching mechanism is based only on URLs, there will be many cases where Spike will not return cached data during Playback even if it has "close enough" data (because the new request URL doesn't exactly match a known URL).
In fact, Spike always stores all data responses and headers that it receives from backend services (up to a limit). This is to enable inspection/debugging at some later time after running a sequence of service calls. But keeping data around also allows Spike to protect you during development and testing in case of sudden or unannounced service downtimes. For example, if you were working on Monday night and everything worked fine, but discover on Tuesday morning that the backend is down — and you had not explicitly Captured data as described in the section above — then Spike can easily use data from whenever you determine the system last worked. This is called "Rewind" mode. It offers you passive protection against service downtime, since you do not need to prep it in advance.
Rewind mode is enabled in the Timeline tab (found in the Spike UI header / navigation bar). To disable Rewind mode and switch to another mode, go to the Capture tab.
Rewinding to a set of earlier responses
Go to the Timeline view and you will see a list of all the recent requests Spike has seen. Find the timeline that contains the most recent working data, click on that timeline, and then click the "Rewind to this timeline" button. Now whenever Spike receives a request for a given service, it will attempt to use responses from the timeline's date, or earlier. If for some service, Spike doesn't have responses at the Rewind date or earlier, then Spike will call out to the service for new data.