Auth?

[brianfeister]

I love your stack, it's the same one that I landed on at about the same time you were committing to this repo.

Have you considered including auth in the base implementation? I've been working with Clerk (which you mentioned in a comment here and have been feeling like "if you're not on a React frontend, you're out of luck" vibes coming from them.

Apologies if this isn't the best place for the question!

[muhwyndhamhp]

Hello, and thanks for stopping by!

I've considered it a lot. In fact, in my personal web I've rewritten the auth so many times (either with provider or hand rolled). But simply for this repo, it boils down to 2 things:

• Haven't found the most convenient yet and performant yet without client side JS and proactive refresh.
• Just started a new job and didn't have the time 😄

I personally goes 180 with Clerk. Used to work pretty good with their V1 SDK, but V2 (I blame theo) pretty much rips out the cookie based server auth for Golang (right now V2 SDK only support API Key Header).

I've reached out to them and their Devrel promises something to go with before public Beta, but yet here we are, no updates to that, not even acknowledgement.

Currently my best bet is just make it your own. But, back to point above!

I'm not promising you anything but I'll revisit this one in 3 months window with a lot of improvement, including but not limited to:

• Component based UI
• Auth
• HTMX Helpers for Headers, and server side control flow (like Redirects, Out of Band swap, etc).
• Database (move things to SQLite, or more accurately LibSQL)
• Some cache control helpers (it's honestly underutilized!)
• Annndd I know I hate to say this, but Bundler support! Just in case you need that frontend library (Like Tiptap or Sortable JS) I'll bring ESBuild here and have it work flawlessly with Go

It's been brewing locally and I hope I can spare more time to finally polish it and get it up lol. Thanks for visiting, by the way!

[brianfeister]

Really good stuff, thanks for such a thorough and thoughtful response!

I bumped into the same issues with Clerk, but I didn't try their V1, so I didn't realize it regressed. You sharing this is super helpful to me because I told my team yesterday "I honestly think Clerk will grow to be more of a problem over time". I said this not knowing they had already demonstrated this and regressed from V1 => V2 in terms of the stack you and I are on

Your roadmap for future enhancements sounds good. I'm 100% AWS via https://sst.dev/ and feeling good about that so far. My project has it's own unique needs, so Dynamo seems best for me and I'm happy with it.

But the goal of course is that your project serve as a reference for borrowing things (actually bundler support for JS sounds amazing! I'm using Alpine and HMTX so far, with some Alpine script tags for minimal client side state management)

If you get around to it, I'm thinking of just running Zitadel on an ECS cluster since it has a dockerized offering (rather than rolling auth myself, which sounds like a rabbit hole)

And while I don't love Kubernetes for it's complexity, the idea of just using an already baked k8s configuration feels like less of a concern to me, and that's an option (docker of course first, the k8s)

https://zitadel.com/docs/self-hosting/deploy/compose