Hayden Falzon

I want to state out of the gate that Elixir is amazing -> But for a small memory efficient server -> I think Golang's tools are superior. If you require more advanced functionality and everything that the beam has to offer then elixir is a better choice (especially when it comes to it concurrency model)

I will be using Elixir moving forward for more of my webhook or sse API's over golang. But I will be using golang over phoenix any day of the week.

Clerks go sdk assumes that you will be using it as a API not a fullstack framework -> so if you will be using go as an API clerk is great... if not... holy moly is it annoying -> I had to do some funky hackery with the JS front SDK with a manual reload and backend cookies to get it working... I wouldn't say it is ideal... but it works... The reason I am (for the time being) willing to put up with this is because everything you get with clerk for a pretty low cost (if your app is making money) is well worth it in my opinion.

I did think about potentially rolling my own auth -> But the pros are outweighed by the cons (as of right now)

If I did roll my own -> I might look into running through a library in the Elixir Ecosystem and then do api calls from the main server side rendered app.

Auth0 is incredibly expensive and very very corporate (I would look at workOS if you are at that level)

As for firebase (which does have a admin sdk for go) -> the documentation was incredibly fragmented -> And on server rendered apps did not seem as secure over clerk, as a lot of things had to be implemented manually.

So I am a big believer in sqlite -> And for a time I thought I would want to set up a file per user. However over time I have come round back to the idea that for now a server based database solution is better suited to write heaver operations when it comes to user data.

For that reason most of the read heavy data such as blogs and content are served through SQLite and the client based data is served through postgres. I use UUID's to keep both databases in sync with each other, though it is a loose sync and is mostly seperate.

The reason I have opted for Postgres and Sqlite over Mysql is because Mysql doesn't offer any advantages over SQLITE or Postgres.

Fastify is great, and I enjoyed it more than express. However its reliance on JavaScript (despite there being a typescript type files) did feel a little unwieldy over time.

Ultimately Golang backend with simple mux for http is more clean, more maintainable and more efficent.

The only downside of go is the ecosystem (Which to be honest is a plus for me)

Since I am serving static files that are run through the backend on go. I just need a way to generate static files. While I could just use go templating -> I really don't like the syntax and prefer using Astro for generating the static files.

If I need to switch later on it will simply be a matter of changing the caching layer and that is about it. Because ultimately it is just generating static files. I am not using any of the fancy features in Astro.