It is always caching!

five keyboard keys on a black surface spelling out the work cache

In October I added multiple account deletion options to the Costs to Expect API – you can delete your data for a specific App, reset your data for one of our Apps or delete your account entirely.

There could be a large amount of data to delete so I decided to handle the deletes behind the scenes with jobs. This worked well and during all my testing, there was never an issue. If an issue does occur a notification gets sent and I can fix the issue.

However, after release, I tested with a throwaway account, and it wasn’t working. As a user I could reset my state but when I signed in again all my data was still showing.

For a little while I was perplexed. The API wasn’t erroring, the data was being removed but Budget still showed the old state. The first hint happened when I tried to do something in Budget; I immediately got an error from the API, a budget item couldn’t be created because the resource didn’t exist.

Aha! I knew what the problem was. I said to myself, “Budget has data, the API doesn’t, there must be a cache issue somewhere.

Budget doesn’t retain a cache so it can only be the API. I rush (really, I did) to my IDE and low and behold, my jobs don’t clear the cache after deleting the requested data – oops!

How did this happen?

Well, that’s easy. During development, I turn off the cache on my local instance of the API as I don’t want the cache getting in the way of any new features I’m writing or debugging. I test before I make a new release, manually and automatically. Though clearly, I’m not always turning cache back on.

The Solution

The solution is easy – do a better job of testing but it isn’t quite as simple as that. I’m going to update my automatic tests to include testing with and without caching enabled. More importantly though, I’m going to expose the API cache status.

It isn’t unusual for the development or staging version of your Apps to highlight their status – a bar at the top, a different background, a visual notifier of some kind. I’m going to update Budget and all the other Costs to Expect Apps to include this notifier and show the state of the API, is caching enabled? Is it in debug mode? That way when I’m testing a data state feature, I’m more likely to spot that status and think about the extra steps.

Don’t create a pointless demo for your App?

Person holding a laptop with the works demo above it.

We wanted users to have a good initial experience with the Budget App so we added a demo. Yes, there was an issue or two along the way but in general, the demo turned out to be useful. When your App crosses the trivial boundary, you need to be able to show users what they can do; there is little worse than signing up to a new App and not being able to do anything because you don’t have any data.

Good initial data

However, the existence of a demo is not enough – it needs to be useful, it needs to include mock data but more importantly, hint at all or many of the features that exist in your App. As developers it is all too easy to create data that is ‘pretty’, we need to create mock real data that will more closely match a user’s real-life experience.

With a blogging App, it might make sense for the initial data to show all the available states a post can have, ‘published’, ‘draft’, ‘scheduled’ etc. – that way rather than seeing a list of completed posts, the user gets to see that posts exist and immediately discovers there is a scheduling system.

Our demo issues?

The demo for Budget creates two projection accounts and ten expense items of several types, that way when a user loads the demo, they get to see how their budget is likely to display and they can play.

So far so good.

Nope, we aren’t exposing all the features; budget items can be marked as paid, disabled and their balances can be adjusted on an ad-hoc basis. These are small features but are part of the general workflow, by being missing from the demo data, we are hoping users find the relevant action buttons rather than letting them know they exist from the start.

Before the official release I am going to review the demo data for Budget and correct the issues I’ve talked about in this post. I’m also going to make a point of reviewing the demo data every few months to ensure we are covering any newly added features.