[throw2ih020]

HTMX is awesome. I've replaced several OSS web apps on my home server with HTMX + Go + PostgreSQL replacements. The results are lightweight, responsive, work great on desktop and mobile alike, all with the absolute minimum complexity required. The codebases are easy to understand and modify, and so far I'm going months between updates (mostly just minor bugfixes for my applications). I fully expec my mature apps will go years if not decades between required upgrades.

[nicpottier]

Are any of these open source? I've gone down the go/htmx/pg path lightly a few times and I haven't loved the feel of it, but maybe I'm doing it wrong. I think just server side templating just starts feeling icky in go so maybe I'm just missing a good pattern or library.

[throw2ih020]

I don't want to ID my account but they basically look like:

- OpenAPI API spec and using https://github.com/oapi-codegen/oapi-codegen/ to generate the types, server interface, and client library

- Standard library http package for the API server implementation

- Standard library template/html package for generating the dynamic parts of the webpage content

- Static web content is embedded within the Go binary (https://pkg.go.dev/embed) and served through server routes

- api served from /api route, htmx webpage served from /

- no ORM, mostly using standard library database/sql package for DB transactions, maybe reaching for a query builder library for more complex queries like complex search functionality

- Local S3 compatible object store for dynamic binary data like user-uploaded images and video. Local filesystem can be fine for small scale stuff.

For my home server I have authn/authz happening at the OS/infra layer, but if you need multitenancy you can pretty easily integrate an OAuth/OpenID authn/authz middleware for login with Google or whatever.

[gavmor]

I just started experimenting with GSX and GSXUI

https://github.com/gsxhq/gsxui

https://github.com/jackielii/structpages is what I might call a framework that GSX sits nicely in.

Also one ai haven't tried: Templ.

https://github.com/a-h/templ

[yawaramin]

I wrote specifically about this, see https://news.ycombinator.com/item?id=48915935

[robertoandred]

How does introducing a third layer reduce complexity?

[throw2ih020]

I'm replacing existing third-party applications which have complex JavaScript frameworks with my "in house" apps using HTMX + mostly just HTML+CSS for most pages and functionality. i.e. I'm not introducing a layer, I'm replacing one.

Why not just use html without HTMX you ask? With HTMX I don't have to reload the entire page to navigate, which is especially helpful for making the app responsive even on low bandwidth connections like a bad cell signal.

[robertoandred]

You said you added a new Go templating layer.

[throw2ih020]

Sorry, I don't follow? I'm just using the templating from Go's standard library. That part replaces existing server-side components of the old applications.

[yawaramin]

No they didn’t…they replaced whatever backend they had before with a Go server, which simplified things overall.

[nasretdinov]

<please don't take this too seriously>

That's great but I believe it's still over-engineered. Unless it's a web site that can tolerate no downtime at all during schema updates, SQLite in WAL2 mode is more than enough. Moreover, in Postgres version upgrades can't be done without significant downtime (or setting up replication and performing a complex dance), so even that isn't so cut and dry.

</ ... >

[throw2ih020]

For some of the simpler sites sqlite would have been fine, but I do need Postgres anyway for some other stuff on my server so the overall burden of standardizing on Postgres only is less than having to do tuning for two different databases. In particular sqlite has worse defaults due to backwards compatibility, so you have to do a lot of upfront config for every table and DB.

Postgres version upgrades are basically painless, at my workplace our upgrades complete in so little time our users don't notice, and we have more data than probably 99.9999% of companies out there (mature company in aerospace industry).

[nasretdinov]

Well if you already have Postgres then yes, sounds fine. I don't really agree that SQLite needs tons of tweaking -- setting journal_mode to WAL/WAL2 is the only real thing worth doing, everything else I would consider optional.

Version upgrades for SQLite are basically a no-op though, that's kinda one of the reasons why it's so great to run in production (and deployment a maintenance being mostly a no-op as well, apart from setting up backups I guess).

I don't actually suggest that everyone should run their production on SQLite, but it's genuinely worth considering especially for small-ish projects.

[throw2ih020]

Foreign key constraints, sync frequency, busy timeout, strict typing on tables, explicit types for integer primary keys, and a convention for storing dates and times are others I would want to do up front.

[Induane]

I set it to enforce foreign key constraint as well.

[inigyou]

Every time I start with sqlite I outgrow it in some way, so I start with postgres now.

[ffsm8]

From an engineering perspective, sqlite and PostgreSQL are equivalent.

The difference is only in the deployment/maintenance.

And considering the context he stated, zero downtime really doesn't seem like something he's worrying about.

[sroerick]

(Me not taking this seriously)

I personally find Postgres WAY easier than SQLite simply because of the deployment story. I do a lot of hotfixes and dangerous stuff on personal projects, and having two databases complicates that tremendously. I like being able to run hot code on prod.

For the record, this is not the same reason I like postgres for actual production code

[nasretdinov]

Sorry can you please clarify what you mean by having two databases? You can share the same SQLite between applications if you really want

[kelnos]

I think they mean that they actually do need Postgres for some of their projects, and it's easier to just use Postgres for everything, than to use Postgres for some things and SQLite for others.

[nasretdinov]

Yes, but on the other hand what I'm implying is that you might not actually need it :)

[sroerick]

Yeah, I mean I guess I could technically connect to the remote SQLite server on my production server. You're right. But I've never done that and that's just not the pattern people use on SQLite

[nasretdinov]

Well, no, I don't think you should be doing that :)

[rtpg]

> Unless it's a web site that can tolerate no downtime at all during schema updates, SQLite in WAL2 mode is more than enough.

I do think that people really underestimate how quickly a system starts being "please, no downtime" (or its weaker cousin, "please, don't make your ops people do rollouts at 1AM").

Like obviously it's not the end of the world but the default assumption of "the system is up" makes a loooooot of things downstream of that easier.

Having to do operational bug triage on systems that routinely have blips in availability is unfun.

[Dylan16807]

Trying to have so few blips they're invisible to bug tracking is a very expensive level of uptime. It takes a lot of convenience to add up that high, compared to ignoring errors for thirty seconds at noon.

[rtpg]

The sort of real thing is that it's not just about no-downtime deploys, but also stuff like rolling back smoothly, general continuous deployment or even just generally being able to easily move between versions.

I still think there are lines (I have to begrudgingly accept that downtime for PG upgrades is still basically worth it because the effort to not downtime there is so high but the frequency is so low), and it's a spectrum. But I've found that this particular flavor of tech debt tends to hurt quite a lot even with fairly low activity systems

[Dylan16807]

I don't think "we restart it to update" counts as debt. It's choosing not to add complicated systems in exchange for uptime.