Ozean Devlog #3: Accounts

I've changed quite a bit of things. From a user's point of view, there won't be many more changes. That is, besides bug fixes, adjustments, and missing features I haven't thought of. To me, Ozean feels like something I enjoy using. Even though it's not perfect, and it can't be. That's the nature of RSS feeds. More on that in a following post.

Client

The site now looks way better and offers some improved usability. There's now an overview of all posts, grouped by their publishing month and year. A dark mode, completely free of cost, is now also available.

Responses containing a 404 or 500 status code used to be text without any styling. They now use the project's page design, though they don't inform what exactly went wrong¹. The navigation on smaller screens is a separate page. It is accessible through a page navigation. The design also feels more cohesive.

The way posts display content is different. They now only show their description when no content is present. It looks better and, to me, also feels better to use. A post includes a small note, when it has no content and displays the description instead. I'll explain why I (have to) do that in a following post.

Server

In the past, Ozean required two binaries to work. One binary was the server, handling all the requests and responses. The other binary was responsible for updating the database every 8 hours. I'm not sure why. Splitting these tasks up this way felt right.

Anyway, the project is now a single binary. I offloaded everything else to little scripts. Running the binary is now easier, as I replaced most flags with environment variables. Ozean always requires the same flags for production. I simplified that process by only needing to remember a single flag. Let's ignore the fact, that I run the binary through a script.

I also made sure that logging logs less. Before, it logged every single request, which can be interesting, but not for me. Now it only logs errors, which is still far from useful². Verbose logging is still an option, useful for development.

The loop that updates the database in fixed intervals is now actually doing it in fixed interval. For real this time. Trust me. The prior implementation added an unintentional small delay each time it ran. That caused a slow shift of the update time away from the intended interval. I fixed that by defining a target time and blocking until that time has passed. When the update finally executes, the program increments the target by 8 hours.

Accounts

Accounts are a thing now, even though the current implementation is a bit lacking. There's currently only support for a single user. I adjusted the database to support more than one, but the reality is that I don't want to have other users on Ozean. At least for now.

As I only need one account, the creation of new ones happens through a script. There is no endpoint for that. The management of accounts is the usual handrolled solution. Encrypt password on registration, compare encryption on sign in. That's it.

By having authentication, I can now add and delete blogs through the browser. No more SSH required to do so.

Sessions

As of writing this, a user can only have a single session. If they sign in from a different location, the server invalidates any active session. It happened to be how I implemented it and right now I'm fine with it. It works for me.

What didn't work for me was the creation of tokens. I wanted a unique identifier as a token. The obvious choice would be generating an UUID. But Go doesn't provide the generation of UUIDs as part of their standard library. That leaves three options: Writing it myself, using a library, or finding an alternative.

Writing it myself should've been the choice but I don't want to write anymore Go. I don't want to add a dependency for a task like this. A whole dependency to generate a string? I'm good. That means an alternative it is.

That's how I stumbled upon Nano ID. From what I can tell, compared to UUID, it's faster and easier to implement. And the implementation only takes up 20 lines of well-formatted code.

What's next

I'd call everything up until this point a prototype or a proof of concept. The original vision for this project was for me to do everything myself and learn lots of things. Somehow I got off the track. So, I intend to focus on doing that again.