Golang

For a while I have been looking for a simple service monitoring tool that didn’t cost anything to run and gave me what I wanted to know: when services are in trouble. Everything I found was either too complicated or partially filled what I was looking for. So I decided to quickly write something up and created go-monitor. TL;DR go-monitor is a simple service monitoring tool. Its primary function is to monitor a list of services specified by the user, and then to notify one or many users if/when these services go down. »

After a fair period of doing research into the industry and various technical considerations, development work on the banking project has started once more. On the to-do list for some time now was push notifications. This is an interesting one as it affects both the server and the client and both are closely tied together. Backend structure I decided to add a separate table for the token storage. This table links tokens to an account, holds the token value, and also holds the platform the token is for. »

Over the past week I’ve done backend work on the bank. These aren’t sexy changes, but definitely much needed. DB Connections When I first wrote the database connections, I wasn’t sure how they worked exactly. I assumed that the database connections were closed on function exit, and that only queries needed to be explicitly closed. I was half right. Go uses a DB connection pool which is meant to be long lived and shared between functions in the application. »

The past few days have been busy. After the big rewrite I had enough done to start the HTTP REST API. I tried to keep the implementation as simple as possible, staying away from big frameworks etc, so I landed on just using net/http and gorilla/mux. The Gorilla Mux is small enough to add minimal overhead abd be close enough to the metal. Implementation With this simplicity in mind, the implementation is easy. »

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. »

In the latest iteration of the banking project, I decided to focus on two aspects first: Implementing tests Proper error handling With the project already well underway, there was quite a lot of refactoring involved and as usual a lot was learned. Testing Difficulties around goroutines The first stop for implementing testing in the current project was looking at the client and the server. The server runs in a goroutine and is intended to be long living. »

Visa recently launched a revamped version of their developer portal. I have previously looked into the Visa and Mastercard APIs, and with this update to their portal I decided to take a closer look. What’s changed? The last time I took a look at the API portal, it was not overly impressive. The front end looked like it needed a good revamp, the navigation was fair and the information was available. »

After building and using the stock notifier I built in Go I am pleased that it is solid and the calculations seem to be working as expected. I recently decided to integrate a Telegram Bot into this system, as an addition to email. I then added some commands to the bot. This process was much easier than expected, taking under two hours from start to finish. Telegram I decided to use Telegram due to its ease of integration. »

Over the past few months I’ve been looking into banking infrastructure, and what it could look like if it was re-engineered with our current knowledge of software. I’ve touched on the UX experience for OTP, as well as started writing the payments portion. As I continue development on this project (feel free to follow along at Github), I continually question assumptions and look for the best alternatives available. My understanding of the banking industry at a software and hardware implementation level (server organisation, regulation application, failovers, etc) is fairly limited, but strong enough to make a decent attempt on how it could be done. »

As part of a larger project of building banking infrastructure, I have begun work on the payments processing aspect of it. This post will detail progress thus far, as well as considerations for future development with a focus on scalability, security and regulations. Adhering to a standard There is currently a standard for a variety of financial instruments in the form of ISO20022. There is a wealth of documentation on this standard, as well as hundreds of XSD files describing each XML structure per type. »