I’m finally ready to start my smoking-web project after finishing the last of the Golang books I wanted to read to prepare.

Today, I finished Let’s Go Further. It’s the second book on Go web dev I’ve read, after Let’s Go by the same author, Alex Edwards. Overall, I’ve now spend about five months to learn Go and web development. During that time, I’ve read three books on Go:

All three were well written. Even though I’ve been programming for about 25 years now, I somehow never did web development of any kind. That’s about to change now, and both Let’s Go and Let’s Go Further were great not just for “Webdev in Go”, but also for web development in general.

Learning Go taught me the basics of Go, together with using Exercism for exercises. It was a good book, at least from my PoV as somebody who has programmed in a number of other languages before.

Next came Let’s Go. It’s focused on writing a web app in Go. It shows all the necessary concepts, from databases over HTML templating to user management and authentication based on an app to show text snippets slowly developed throughout the book. It is heavily focused on the code itself and uses the implementation of the different concepts in the app to explain them. I quite enjoyed going through it, and it covered exactly what I needed to know, including security concepts like cross-site request forgery protection. I very warmly recommend it. But also a fair warning: It’s not an appropriate first book on Go, as it focuses on using Go for web development, not on Go itself.

But there were a few things the book didn’t cover, e.g. how to handle database schema changes or JSON APIs. And that’s why I decided to also read the second book by the same author, Let’s Go Further. It follows the same approach as Let’s Go, explaining the concepts based on the code for an example app that’s developed throughout the book, only this time not as a web app, but a purely JSON API.

Smoking-Web

I’ve already provided a short overview of the project I’m planning in a previous post, so I won’t go into too much detail on the fundamentals. In principal, I’ve already got a CLI app which allows me to log when I’m having a smoke, and tells me whether a configurable interval has passed since the last smoke. It’s a small tool which allows me to avoid smoking too much.

The idea now is to reimplement it as a Go web app, so that I can also use it on my phone. In addition, I want to implement a JSON API and switch the CLI tool to using that, so I can have one central database. The rough plan looks as follows:

  1. Project setup, with repository and CI
  2. Implement web UI basics and user handling
  3. Implement JSON API
  4. Implement releasing and deploy in k8s cluster
  5. Implement JSON API as a backend for CLI tool
  6. Run an import of the last 11 years of smokes from the CLI database
  7. Implement the rest of the web UI, so that smokes can be logged from the website
  8. Longer term: Play a bit with JavaScript visualizations to implement a few metrics and graphs

So I decided to start with the JSON API as my first goal. That’s because without it, I would have two data sets: The local DB from the CLI app, which I use when I’m at my desktop or laptop, and the database of the web app, which I would fill while on the go. That doesn’t make much sense, so I will start out with the JSON API and the migration of the CLI tool.

The Migration of the CLI tool will actually be rather interesting too. It’s written in C++, and hasn’t been touched since 2018. There just never was any reason to, as it’s only external dependency is the glibc and SQLite, and those aren’t exactly changing much. So I will likely need to hammer it into shape first, getting it to compile without warnings with newer GCC versions and fixing all the new linter warnings which will likely start to show up.

One thing I’ve been thinking about is whether I will want to use one of the Go web frameworks, like Gin, or whether I want to follow the path Let’s Go has shown me and just use what’s available in the standard library. As I’ve noted above, anything I’d need might already be available or be rather easy to implement on my own. So that’s likely the path I will choose.

Another thing I’m currently considering: How to architect the two use cases, the JSON API and the web app. My main consideration is how to do API access. Should I basically have HTML forms for the web app and separate JSON endpoints for the API, or should I be using the JSON API in the web app as well? That’s something I will have to read up on a bit and see what the current wisdom is. It feels like using the JSON API in the web app makes a lot of sense, so I won’t basically implement two APIs. But, on the other hand, I think that also means that where I could normally just use plain HTML, I would then need to use JavaScript?

Another point that’s still open concerns the web app itself. The primary functionality would be a page which shows when the next smoke can be smoked, according to the last smoke time and the currently configured interval. But how would I make sure that the time gets updated when, in the background, another smoke was logged via the API? In theory, I think I would need to make constant GET requests. I’ve already heard about one possible solution, namely Websockets. Those would involve a bit of JavaScript, but would allow me to push updates from the server. But it would also mean a constant connection? On the other hand, it might be possible to set something up with the Page Visibility API, so that there’s a bit of JavaScript which runs a GET request every time the tab the page is loaded in is actually focused? That sounds like a good compromise to me, at least. What I would really like would be to not just run a GET request to get the newest smoke time, but just reload the entire page? It would keep the logic a bit simpler I’d think, compared to fetching fresh data and updating only parts of the page via JavaScript.

And finally, I’m still a bit daunted by the “Looks&Feel” part of the implementation. Does anybody have any good tutorials on HTML/CSS? Not so much on the syntax, but basically “Get from ‘unstyled’ to ’looking okay-ish’ in these 57 simple steps”? So something which guides you through writing a “general purpose” stylesheet which is at least a smidge better than unstyled HTML?

Well, lots to think about before I can really get this off the ground.

I’ve been thinking about some actual programming posts, but I don’t generally find the kind of “Here is some code I wrote…” posts that interesting, unless they’re doing something interesting - and let’s not pretend that the above is anything but a CRUD app that has probably been written 1000 times, just with slightly different names for the data-holding structs. 😉 So let’s see how much of the implementation I will actually deem interesting enough to share.