Bank update: Errors, tests and responses

This is more of an incremental update from the last post. I’ve spent loads of hours carrying the changes for testing and error handling across the entire project while making sure there is not a break in functionality.

In addition to doing this, I have also started to seriously investigate some prepaid solutions, which I will go through at the end of this post.

Errors and tests

I finished a big implementation of testing and error handling - 1400 lines added, 400 lines removed. All packages now have good testing, and can be added to going forward knowing safely functionality will not break.

The exception is the payments package. I don’t like tests that leave traces, so with users and auth testing I have the records created and destroyed, both in MySQL and in Redis. When it comes to payments, this situation changes somewhat.

Outside of the complexity of having to create users to do the transactions between, there is the matter of having records left in the database. Transactions should be immutable, and this means that the tests will leave behind records and dirty the database. There may be a way to skip the actual insertion and just test it, without affecting the core code, but I have left this for another day.

With regards to all the errors, they are now returning a nice trail. Every time an error is caught, the function that it is caught at is added to the chain, so you could have an error that returns:

Error: Client.ProcessRequest: Accounts.CreateAccount: Accounts.InsertAccountIntoDatabase: Invalid SQL syntax, please check code at XXX

While the above is great for debugging, it might not the best for returning to clients. I will be looking into moving this into some form of code returned and logging on the server side.

Responses

I will be starting work on an HTTP API to mimic the already existing functionality of the CLI API. This HTTP API will be used by the mobile clients (and others) to access records and execute actions. In order for this to be handled properly, and for the errors above to be handled nicely all the way through, I had to abstract the responses accordingly.

The errors and responses get returned all the way through to the calling function, and then they get parsed according to the caller originator. For the CLI API, they get parsed into a string and returned on the TCP channel. For the HTTP API it will be changed into an HTTP status code and a message.

Pre-paid

I have been doing loads of research into bringing this project into the real world in the next three to six months, and one way to do so is by integrating prepaid cards. Quite a few companies have done this, new and old, to offer financial functionality without having to build out the infrastructure and handle all of the regulations.

The long term goal of this project is to become a fully fledged bank, and a stepping stone to that is to integrate the prepaid cards. I am in the process of talking to a few card providers and should be able to shed more light on this in the coming weeks.

This is an exciting time, if you want to get involved you can get in touch with me or offer your support.

Conclusion

The past week has been a great learning experience, and the project is now becoming really solid. The changes made add greatly to its stability and resilience, bringing to it good coding practice and architecture.

Next week I will begin work on the HTTP API, and as the functionality is already available it should be relatively quick to implement (especially in Go). From then on out it’s back to some iOS.