Introduction

Author's note: This article is not technical in nature.
Rather, it is a set of reflections and a fragmented stream of thoughts, something to read on the subway on the way to work.
It should not be taken too seriously.

Let's begin.

In the previous part
I briefly described my adventures while developing a WAL receiver.
Now it is time to continue.
Not because I need it, not because anyone else needs it.
Some things simply happen on their own, like you were just asleep a moment ago, and now you are already writing notes in the margins.

It all started with a timid internal question.

What if I attach the simplest possible web panel to the application? Sounds like an excellent idea.

Exactly until the moment you remember one small detail: you do not know how to write frontend at all. Not at all.

That is, at the level of ideas - yes, of course, now we will quickly make a neat web face, a couple of pages, a nice status view, tables, buttons. In practice, however, it looked roughly like this:
"Oh, cool idea."
Five minutes later:
"Wait... but the last time I touched frontend was who knows when."

But from a certain point, the idea became not just good, but truly tempting. Because if a task does not contain at least a drop of adventurism, self-deception, and light engineering recklessness, is it even really my project?

What Skill Loss Is

A couple of years ago, I already had a period when I studied frontend. And, to my surprise, I even liked it back then.
Specifically, Angular, the second one, the one on TypeScript.

Why Angular?
Because at that time, I was working with Java, and Angular seemed suspiciously similar in structure.
Understandable entities - services, components, dependency injection - all of this at least resembled not shamanism, but some kind of system. Yes, on top of it all, there was a generous sprinkling of HTML, CSS, and other frontend rituals, but in general, there was no feeling that you were picking at an ancient altar assembled from npm packages and developers' tears.

That is, back then, frontend did not look like hostile territory, but rather like a strange but tolerable neighbor.

But the years passed, and all that knowledge evaporated so thoroughly as if it had never existed.
Not "I kind of forgot it", not "I need to refresh it", but precisely disappeared. Evaporated. Erased. Drowned somewhere between work tasks, Go, infrastructure, Postgres, Kubernetes, and other things that do not require discussing which state manager is fashionable today.

When I tried to look toward modern frontend again, gloom caught up with me rather quickly. And not some noble gloom, but the ordinary,
everyday kind: when you look at yet another stack and realize that just to start, you first need to reread half the internet, then install a thousand dependencies, then understand why it does not build, and then also find out that all of it already became obsolete yesterday.

And at that moment, it became clear: no, I am not climbing back into this from scratch. Life is one, and node_modules is unfortunately much larger.

With that thought, I successfully put the idea aside for a year, threw it onto the shelf to gather dust together with other intentions sprinkled with laziness.

Sometimes the Solution to Forgotten Problems Happens by Itself

One day, while reading some random projects on GitHub, I stumbled upon htmx paired with Go. After digging further, I realized that this is a perfectly workable pattern.

And then that rare feeling happened, when, instead of irritation, there is almost childlike joy. Suddenly, it turned out that you can avoid arranging a second higher education for yourself in SPA magic and make everything much simpler.

In pure Go, with templates, with functions.
Without a giant frontend stack.
Without worshiping "reactivity".
Without the feeling that, for the sake of two status pages, you are obliged to build a small copy of the modern web industry.

I immediately felt like Eric Cartman -

[breathless] Mom-Mom! I've only just heard.
They're making Chinpokomon dolls, mom.
You can collect them all.
You can collect them all, Mother; quick, come on. Let's go to the toy store!

Forward, this needs to be done quickly!

Planning and Implementation

That is, in essence, you can build a completely normal single-page application - not in the sense of "a revolutionary interface of the future", but in the sense of a normal, honest, utilitarian status page. One that does not try to impress investors, but simply shows you what is going on in the system, and preferably without unnecessary complications.

After that, the idea suddenly stopped being nonsense and turned into a plan. A dangerous symptom, by the way.
This is exactly how the story of any side project usually begins:
"I'll just try a little."
And then you look - you already have architecture, API, UI, separate models, and for some reason you are seriously discussing the convenience of switching between receivers.

Then everything went according to the classics of handcrafted engineering creativity. I quickly sketched out
what it should roughly look like, wandered around websites, peeked at other people's templates, assembled a general style in my head, and began drawing a mockup.

The old-fashioned way - on paper.

Yes, literally on paper.
Not in Figma, not in Sketch, not in anything else fashionable and respectable. Just a sheet of paper, a pen, rectangles, labels, arrows. Like a person who is not fighting
for the title of "frontend developer of the year", but simply wants to understand where the WAL files will be and where the refresh button will be.

And, honestly, there is even a certain charm in this.
When you have no claim to "world-class product design",
it is surprisingly easy to focus on what is actually needed.

And what is needed, in fact, is quite simple.

First, such a panel really helps with debugging.
You do not have to climb into the container every time,
wander through directories, run yet another ls, find, cat, curl, and pretend that this is normal UX for a living human being.
You open the page, and there in front of your eyes are WAL files, backups, configuration, and overall status. Everything in one place.

Besides, an important part is that you can run a check for the existence of a backup, take its end LSN, select all WAL files, make sure that none of them are missing, and that recovery is possible. Next in the plans is to make something like a recovery verification as an option.

Not that this is merely an option; rather, it is the most important thing in the process. If a backup is not verified, then consider that you do not have a backup at all.
But as a rule, such checks are performed manually (I do it myself too, sometimes not too often because of laziness).

And with an interface and the possibility of automation, there will also be a desire to perform checks more often; besides, it is not just interesting, it adds peace of mind.
Beauty? Well, maybe not beauty, but not archaeology either.

Second, you can switch between receivers.
Because, of course, there may be several of them.

Initially, of course, I did not plan to do this.
At all. Not because the idea is bad, but because it seemed like one could live without it anyway. The console suits me 500%.
Plus, any website immediately causes natural suspicions: now there will be polling, background requests, endless updates, meaningless HTTP load, and in the end, you will attach a small source of indignation to yourself.

That is, first you make a panel "for convenience", and then you catch yourself realizing that the panel itself has become the thing that needs to be watched. Very engineering-like.
Tests for tests.

But then I thought: what if I do not turn it into a hysterical television with constant flickering?
What if I abandon endless polling loops and automatic observation altogether, and leave only manual refresh?

And suddenly everything started to look very reasonable.

Because in this form it is, in essence, the same curl request - only in human form. No watching-cycle, no background fuss, no unnecessary magic. Wanted to - opened it. Wanted to - refreshed it.
Looked at the current state, got the information you needed, and moved on.

That is, without SPA, without multilayeredness, without assembling a universe for the sake of a couple of tables.
Without the feeling that you accidentally subscribed to a second project instead of making a small improvement.

Just Go, templates, htmx, and a bit of adventurism.
And sometimes, oddly enough, that is quite enough.

Closer to the fifth version, the implementation began to resemble what I had drawn in my imagination. Of course, smart people would have done it more correctly, while putting in less effort, with a more reasonable structure, using the right tool.

But - sometimes a hammer, a stick, and swearing work wonders.

Conclusion

The dashboard started working, release 0.1.0 is ready to start using it.
From here on, it can be improved and polished.
Since this is a fully optional component that is not connected to the main application in any way (although the sources do live in the root of the project), it is possible to plan separate levels of development.

Repository: https://github.com/pgrwl/pgrwl

Thank you for reading to the end!