Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

31–40 of 40 posts

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

#31

Post by moh_quz »

twodave wrote: post #30
CalRobert wrote: post #28

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 par…

This is really helpful context, thanks for writing it out.

You’re right that Next wants to be your backend and thats exactly why I kept the real backend separate in Go.

The Go backend handles all auth, billing, database, everything.

Next is just a frontend that calls the API. So if Next keeps changing things or pushes too hard toward Vercel, you swap it out. The backend doesnt care.

The white-label / custom domain point is interesting, hadnt thought about that edge case. Good to keep in mind.

Honestly the backend is the important part here. The frontend is just one way to consume it

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

#32

Post by srameshc »

zaphodias wrote: post #20

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 for sharing. I am particularly interested in knowing your experience with ConnectRPC. I wasn't aware about this library. I use Go and JS implementation in one of our webapps and it was painful specially on the web but once working it was beautiful. Just curious if you feel it is a much better developer experience with ConnectRPC ?

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

#35

Post by d0100 »

moh_quz wrote: post #6
adlpz wrote: post #5

Cool project! Will surely copy ideas from it :) A general question for the room: where's the tipping point where you need a "proper" backend, in a different language, with all the inconveniences of possible type safety issues and impedance mismatches? Because I feel like for 90% of small-medium projects it's just good enough with all the backend stuff within the same Next.js process as the front-end. I just do "separ…

You're not doing it wrong. For most CRUD apps, Next.js + tRPC is the right call. My tipping point was long-running tasks (OCR, AI processing that takes 30+ seconds) and wanting to scale backend compute separately from frontend serving. If you don't have those needs, stick with what you have.

dbos.dev should take care of long-running tasks, but I haven't tried running too many tasks yet as my other bigger projects all use Temporal

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

#37

Post by moh_quz »

Joel-LeBlanc wrote: post #36

[flagged]

Thanks and appreciate your compliment!

The deployment process for this repo has been really smooth for me. I use only docker compose, and traefik for web server.

ngl I ran claude code to help me for deployment, and then I wrote scripts automating deployment of frontend and backend.

All of this I used it for my product apflow.co

If you need to know more, please you can contact me, you will find my info in the repo

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

#38

Post by aforwardslash »

krsoninikhil wrote: post #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

Nice work! I have something similar, but its a bit more generic and extensive - https://github.com/oddbit-project/blueprint

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

#39

Post by twodave »

moh_quz wrote: post #19
rvz wrote: post #17

Nice project and great idea and a reasonable selection of technologies that optimize for low cost deployment. However, my biggest concern is the glaringly lack of comprehensive tests whatsoever. I have to even question if this project is production ready at all. Until that is in place, I really do not think this is "production" quality I'm afraid.

Fair point. For what its worth I did add a script that runs tests and checks coverage. But yeah the coverage itself could be better, working on it PRs welcome if anyone wants to help out

Eh, don’t let other people define what is acceptable for production. Tests are nice but for most boilerplate type things nobody (and I mean NOBODY) writes unit or even integration tests. If you are deploying with the tolerance that you need this stuff to be automatically verified then you’re probably going to be running automated e2e UI tests anyway, and those will naturally uncover regressions and other issues with your auth backbone and other basics.

Source: self, from “shipping to production” for multiple decades

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

#40

Post by zaphodias »

srameshc wrote: post #32
zaphodias wrote: post #20

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 for sharing. I am particularly interested in knowing your experience with ConnectRPC. I wasn't aware about this library. I use Go and JS implementation in one of our webapps and it was painful specially on the web but once working it was beautiful. Just curious if you feel it is a much better developer experience with ConnectRPC ?

Did you mean gRPC maybe?

In any case, my experience so far has been great. The connect-es generator takes your protobuf and generates a TypeScript library which looks pretty good. You can use ConnectRPC both from the browser and from Node.js (the latter can leverage HTTP/2, while the former uses the native fetch() or a function you provide).

Post reply on HN