Successfully Writing an App and Going Beta

I think it has taken just about four months over the winter to get an app from paper to something totally functional. The app is intended for exclusive use at the end of the day, so I won’t refer to much specifics. I had set two objectives that I wanted to accomplish when I began this project. The first is to learn my chosen tech stack: Go, Gin web framework, Postgres, htmx, JavaScript, html, and Tailwind. My second goal is to complete a piece of software that is much greater than the typical CLI apps I would build at my day job.

The app isn’t anything ground breaking, it definitely took way longer than an experienced full stack dev to produce, and the UI and overall front end presentation isn’t the most ideal. No matter what expenses were made, this has been a really proud moment where I can say I had produced functional software that I am proud of!

The outcome of my work is a functional, fast, and lightweight, web application. I tried to take advantage as much of server-side rendering as possible (which seems to be the current trend from what I gather). The application should by design be easily deployed, either locally or on the cloud and offered as a SaaS. By its core design, it should be easily accessible from any device with a browser. It is also (in my opinion) easy to refactor and introduce new features in the future.

Tech Stack

The tech stack chosen (Go, Gin web framework, Postgres, htmx, JavaScript, html, and Tailwind) are all entirely new to me. I had never used any of these technologies before. I did try to make informed choices in selecting the components for the stack.

  • Go: Generally accepted as an excellent web back-end language. Easy to use and a pleasure to develop with.
  • Gin: While I originally relied on the Go standard library for http functions, I found using Gin definitely provided convenience with reducing boilerplate. At this point, the app doesn’t use an immense amount of tooling offered by the framework, but I wouldn’t doubt I can take advantage of some more in the future.
  • Postgres: I have some SQL Server experience before; mostly similar, not too unfamiliar and has been easy to use.
  • htmx: In an effort to keep the development lightweight and performant with SSR. Again, at the moment I am probably under-utilizing; there’s a lot of features I want to take advantage of. I would probably want do a full refactor to take advantage htmx wherever I can.
  • JavaScript: I can definitely say I’m not a fan of JavaScript. Syntax is not really fun to follow. Had to constantly use references to get it right.
  • html: Pretty self explanatory for a web app.
  • Tailwind: Originally tried to use vanilla CSS, but just like Gin, the framework greatly made the styling work much more pleasant and quick to use.

I don’t know how my application will develop into the future, but I wanted to have a stack that shouldn’t easily get outdated either.

Lessons Learned

From my perspective, web programming is hard! Specifically, UI designed coupled with functionality is hard! Writing the application layers and handlers were mostly trivial. Though this experience has shown me I need to spend more time with web development. On one hand, it’s sometimes difficult getting a template to behave the way you want it to. At the same time, I don’t have foundational design principles to keep a nice UI intact. While the application certainly isn’t “ugly”, there is going to be room for improvement. I think my project planning may pay off, as I can visualize how I can upgrade and refactor components relatively easily.

Keeping the majority of the code decoupled and modular certainly has been a benefit. As I continue to finish adding basic features, I found I had to constantly refactor everything that was “wrong” when I first envisioned what the code should look like and how its functionality behaves. When I reached times when handlers are finally ready to connect to the templates, I discovered I implemented a lot of things wrong initially. This forced me to refactor a lot of the code in the handlers and service layers. I also learned I should not write all my back-end code first (or front end first for that matter), but rather I should write per module or component.

Going Forward

The next step is to beta test the app and get some user feedback. I probably want to take a little break and just distill everything I experienced so far. When I am ready I’d like to do some full refactoring, primarily to really produce much more beautiful UI designs.