I’ve been working on a personal finance web app called Iron Money for the past couple of years. In September 2008 I released it as a private beta; you could sign up and use the API, but to actually use the web app you’d need my approval. Last week, I made the Public Beta available for everyone to use—no special approval, just sign up and go.
This post is an in-depth look at the kind of decisions that went into making the current version of Iron Money.
Simplify
I focused on making this release as simple as possible. I wanted a simple, well-tested foundation for future versions of Iron Money; thus, I actually cut features from the private beta. I wasn’t happy about cutting some features: I think the undo/redo feature was great from a usability perspective and the budgeting feature was something that was very useful. By the end of September, however, I knew that if I was going to get the public beta out the door, I’d need to cut down on things for the initial release and focus on the features that were core to Iron Money’s purpose: keep users up to date on their finances.
The simplification theme extended to the features that were kept as well. For example, I changed how categories worked so that they were easier to use (Iron Money used to have four default categories, two of which could have children categories; now, it has three default categories, all of which can have children categories).
Everything has a UUID
One of the things that changed fairly early on was my move from using MySQL’s auto-incrementing primary keys as IDs to using UUIDs for IDs. The primary reason for this change was my desire to make sharding user’s data easy. With UUIDs, I don’t need a central table dictating the IDs for everything and I don’t need a complicated auto-increment scheme; instead, I can add as many shards as I want to as Iron Money’s user-base grows.
Everything has an ETag
Iron Money now keeps track of an ETag for every resource. In a future post I’ll talk more about how Etags are used by Iron Money, but creating an ETag for each resource allows Iron Money to support better caching through the API. Whenever something is added, edited, or deleted from Iron Money, at least one resource’s ETag is updated.
api.ironmoney.com
Iron Money now uses a new domain exclusively for the API. This was mainly brought on for security reasons: I didn’t want any cookies set on ironmoney.com to be available on api.ironmoney.com. Furthermore, I think it’ll make it easier to run the API on a separate server in the future.
OAuth permissions
Iron Money’s API now supports a permission system that is fairly flexible: instead of authorizing an application to access all of your Iron Money data, the application can limit itself to just what it needs to access. For example, an application can ask for read permission to your accounts if it wants to show you your latest balances, without requiring read or write access to anything else.
The permissions system is a win for both third-party applications and users. Users have a clearer understanding of exactly what they’re authorizing an application to do, while apps can prove that they are only reading your information (instead of making it just a trust issue).
Almost everything is cached
a href=”http://memcached.org/”>Memcached is an amazing caching system; if you’re not using it in your web app or API right now, you’re missing out on faster reads. Basically, whenever data is written to Iron Money, it updates its cache and almost every subsequent read is from memory.
Simple can be difficult
Rewriting Iron Money over the past few months has been a lot of work, but I think the changes above will pay off in the long run with a faster, easier to use Iron Money.