As a father of 2 young children, finding spare time to learn new things outside of work is difficult. Originally, this began as a reflection of a year in the Golang software language, but that only tells a part of a wider project.
Instead, I want to talk about trying to get a software service product off the ground. Starting off I had an idea of the end goal, what I needed to learn to get there, & which tooling I could use to make it a reality.
A key theme I can reflect upon from the start is I had an underappreciation for the size of the problem in context of space I had to work with around existing commitments. Especially for something as large as a web app budgeting application.
A year in, I have learned a lot & still see a fair amount of pathway to go.
Where to begin
The Start
Thinking at the start was that the most rapid fire way to get this off the ground was to be cloud native from the start. Which I still do not think was the worst possible idea, although it was not exactly helpful for seeing an outcome.
I opened up an AWS account & drew up a database diagram for myself. Then I learned how to create the necessary collateral in my AWS trial account, connect & create the database via beekeeper & execute scripts.
The core problem here was that I should have developed the database locally 1st based on the diagram. Then have a local application connect to it, rather than spend time interfacing with the cloud. All I did was burn through “free” credits & introduce complexity that had to be taken out later.
My database design has since lived in the instantiation script as I have fixed all the logic problems I have headbutted into. The original version is quite out of date and lacks a few tables!
Developing with Golang
Golang has a helpful “Getting Started with Go” tutorial, which I had been dabbling into by the end of 2022. It was the main language for the backend at the company I worked at the time.
I decided to build my budgeting web app with a Golang backend, thinking I could get a backend -> api -> frontend flow up & running on AWS for a launch sometime in 2024. It is a more straight-forward pattern compared to the backend team was using, so I knew it was a viable choice for a real-world use case.
While a lot of ideas / patterns / concepts are transferrable across languages (assuming they’re tools for the job at hand), Golang has solid support for the web server + router + handler pattern for APIs.
A lot of my learning & usage of Go has been tackling problems as they came up with the budgeting app. It started with boilerplate concepts from YouTube videos, questions to ChatGPT & Gemini & now I am thumbing through the book “Let’s Go” by Alex Edwards. This book is to improve the API implementation that I have functionally working to a higher standard.
The trade off of approaching problems as they need to be solved has been largely positive to work through & stay motivated.
While I may not have an in-depth grasp of all the capabilities, I find the differentiator of knowing how to do something is objectively more valuable.
My favourite learning space with Go has been using scripts to tear-down & re-instantiate test data at runtime for my local environment. Second, use of debugging tools on local instances. Anything to make my time more effective is appreciated.
Consistency of Effort
Looking back at my contributions, it really comes clear that consistency and spending time build the drive to continue. While I think I am missing a lot of “work” from purely looking at GitHub contributions, it is still a good indicator of when I did save tangible, built work.
Notably, time spent in AWS, time spent researching how to best self host a blog, & application debugging do not really come through here. I cannot miss though; it is a great signal of when I did work.
A major note is the gap between end of June to early October in 2023. This is because AWS “free” tapered out & I deprioritised refactoring for debugging locally for other activities in life. Going back to the gym and getting out of the winter funk really helped here.
Achievements
I consider my main time with Go to be from about March 2023, when I stopped playing around with AWS. When I started building the core functionality of the app, I wanted to have.
Right now, I have:
- Baseline of API endpoints that enable different request types to maintain a budget to the transaction level. The core product, essentially, in backend form.
- API response codes and relevant user messages as per IANA standards, with a security focused / trust no one mindset.
- A connection to a data store and the ability to tear down and re-start with demo data.
- Tooling to use the API in runtime, view into the data store in beekeper and data states in the IDE.
- The building blocks for user authorisation & authentication.
On my roadmap are:
- Reporting layer on a user level.
- Stronger data sanitation & validations.
- Design how I want the application to look and be used.
- Work out how to connect the frontend and backend securely.
Learning Highlight: Reflection to update APIs
A pattern I have found really fun in Golang is the use of reflection to take an incomplete object structure and update an existing object without losing any of the previously known data.
This greatly enhanced the surface area of the PATCH endpoints for a given API in my budgeting application. Here is an example of the code used:
Keeping up with movements in the development language
Since starting with Go, the standard library has expanded its capabilities in the server + router + handler pattern for API requests.
Keeping up to date with a language’s base capabilities is important as it reduces dependencies on 3rd party libraries & their maintainers keeping interest.
A key highlight & way of doing this was the release of Go 1.22. I took out the mux package & explored the new standard library implementation, the NewServeMux function. It also really tested my knowledge of how the pattern was setup & how to transpose the code without a tutorial or rubber ducky.
Lots of other features have been released in Go over the past year. It is not about keeping up with them all, as I trust I will discover & learn them as required.
Yet when the chance comes to simplify the codebase dependencies, I put value into taking the chance, given there is no loss of core features & capabilities.