UX: account balances and amounts on the transactions API

[sebinsua]

While adding the list balances command to my CLI I stumbled upon a couple of things that made it harder to implement than I expected.

1. At the time of a transaction we do not know the account balance. I had to work this out by getting the current balance of an account and subtracting the amounts against transactions one-by-one until I reached the date I wanted a balance for. This is awkward.
2. While summing transactions I ran into another issue. Currently the amount of a transaction is sent in the JSON as a string. On deserializing I convert this into an integer by multiplying it by 100 - as using a float would create issues. It might be easier to send all numbers as integers by default.

Taking a look at Mondo's API it seems that they've simplified both of these things. An account_balance is provided against each transaction as well as an amount. Additionally both of these numbers are provided as integers in 'minor units' (e.g. pennies).

Making these two changes would have made it easier to write the app I created (and presumably others similar to it.)

Your thoughts?

[stevegraham]

+1

A running balance will be added, but it's one of those things that will need to be left until more banks are added in order to determine the best way to implement it.

Amounts are expressed as "123.99" because all numbers in expressing them in integer units is unwieldy, and also not all environments have fixed point numbers, e.g. JS. The way to work with numbers expressed like this is to use fixed precision support in your language. e.g.

require "bigdecimal"

n = BigDecimal.new("123.33") + BigDecimal.new("99.66")

puts n.to_s("F")
# => "222.99"

Fixed precision is available on other platforms too, e.g. Android BigDecimal and iOS +[NSDecimalNumber decimalNumberWithMantissa:exponent:isNegative:] to name two.

[sebinsua]

Hm, good point about using a proper numeric type. Rust didn't have one in its standard library but I just looked and actually there are two crates that provide them (some of which have serialization support) so I'll use those instead of converting everything back-and-forth from integers.

Running balance would definitely be a useful feature though. It's very messy to add it in after the fact.

Does it really have to be left until later? If you know the current balance and each of the transactions that lead up to that, you should be able to generate it retrospectively - are there cases where any of this information is missing?

[stevegraham]

This is master and will be going into prod.