Live data from Hacker News

Show HN: I open-sourced my Go and Next B2B SaaS Starter (deploy anywhere, MIT)

github.com

21–30 of 40 posts

Re: Show HN: I open-sourced my Go and Next B2B SaaS Starter (deploy anywhere, MIT)

#21

This is great - thanks for sharing. I am actually building something very similar myself as I started building a couple SaaS and though it would be nice to extract the common pieces in a template. My stack is similar, with a few differences: - Go backend with sqlc, but using ConnectRPC[1]. I chose this as it allows me to define a proper API scheme and generate a decent-quality Typescript client. - Nuxt (Vue) instead…

Thanks man, really appreciate it!

ConnectRPC looks interesting actually, proper API schema with generated TS client is nice. And that Nuxt dashboard template is clean, hadnt seen that before.

If you spot anything in the repo or have ideas, feel free to open a PR. Or just reach out directly if you wanna chat about the stack. Always down to learn from someone building similar stuff

Re: Show HN: I open-sourced my Go and Next B2B SaaS Starter (deploy anywhere, MIT)

#23

Have you tried Echo instead of Gin? I find it to be much more friendly and approachable with its docs compared to Gin.

Tbh not yet, I heard that it’s more user friendly, but I go with gin because it has larger community and support!

Would love to explore different libraries

Re: Show HN: I open-sourced my Go and Next B2B SaaS Starter (deploy anywhere, MIT)

#24
This seems helpful. If you're writing new applications frequently, have something like this really helps.

I created a simple start kit set of packages for my projects, not as exhaustive as yours though -- https://github.com/krsoninikhil/go-rest-kit

Re: Show HN: I open-sourced my Go and Next B2B SaaS Starter (deploy anywhere, MIT)

#26

This seems helpful. If you're writing new applications frequently, have something like this really helps. I created a simple start kit set of packages for my projects, not as exhaustive as yours though -- https://github.com/krsoninikhil/go-rest-kit

Just checked yours, it is really helpful for those who want to start quickly, some people won't use mine because it is too much for their use case.

Thanks for your feedback, and I am always open for any questions!

Re: Show HN: I open-sourced my Go and Next B2B SaaS Starter (deploy anywhere, MIT)

#27
post #7

Thanks for sharing! One question though: What made you avoid lock-in via platforms like supabase but then choose to be locked in on the AuthN/Z side with a proprietary solution?

Fair question. The difference for me: Supabase lock-in is deep (their Postgres extensions, auth hooks, edge functions all intertwined). Stytch lock-in is shallow (just an API behind a ~200 line adapter). If I swap Stytch for Ory or Auth0, I rewrite one file. The rest of the app doesn't know the difference.

Fair, that makes sense!

Re: Show HN: I open-sourced my Go and Next B2B SaaS Starter (deploy anywhere, MIT)

#29

Can I ask why Next? I’ve been suffering with it for ages and desperately missing Vite.

Honestly just because its the most popular so more people can pick it up easily.

But the frontend and backend arent tightly coupled at all.

You can swap Next for Vite, Nuxt, whatever you want and connect it to the same Go backend.

Only thing you'd need to copy over is some auth and billing related stuff on the frontend side

Re: Show HN: I open-sourced my Go and Next B2B SaaS Starter (deploy anywhere, MIT)

#30

Can I ask why Next? I’ve been suffering with it for ages and desperately missing Vite.

Next is an ok choice (IMO), but there are definitely some things Next does that you want to be aware of up front.

* It wants to be your back-end. If you have a separate back-end, get ready to write back-end auth code twice, and probably in 2 different languages, and some brittle proxy code that will break the next time the Next guys decide they want to change how middleware works (again).

* The maintainers aren't particularly helpful. Having built a couple sites using Next, many of our questions ended up being answered with some variation of, "You're holding it wrong," but it was clear they just didn't want to support our (and other users' submitting issues) scenarios.

* Whether you are on Vercel or not, the team behind Next is very motivated to get you onto Vercel. You can expect their technical choices to go more towards that path. This is at odds with the goals of this project. Coupled with the above, expect to have little to no agency to raise issues and have them solved beyond simple/obvious bug fixes, even after you've invested your project into their platform.

* Next really struggles in situations where your users are your customers' customers, and your customers want something more white-labeled. As soon as this bleeds into the arena of using custom domains per customer and such, some of the advantages of Next start to become disadvantages.

Many of the pieces Next offers are sort of optional, but if you don't fit their idea of how a piece (such as auth via next-auth or their take on server-side components) should work, you're left to solve on your own. It's not the end of the world to have to implement your own auth flow with oidc-client, but it can be a little risky and my brain doesn't hold onto OIDC or OAuth2 so every time I implement an auth flow from scratch I end up having to look up how it should work.

That said, if you end up having to deal with more than a couple of the above things, Next moves from an ok choice for the project to a poor choice.

Post reply on HN