Oh boy another template shipped in a single commit; complete with "For now, do this" and "In production you would do this" comments
adlpz8 minutes ago[-]
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 "separation of concerns"-ish with the code organization and funnel all communication with something structured and type safe like tRPC.
Feels separate enough but very pleasant to work anyway.
Am I doing it wrong?
moh_quz3 minutes ago[-]
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.
sallveburrpi10 minutes ago[-]
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?
moh_quz2 minutes ago[-]
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.
miroljub17 minutes ago[-]
Nice one. Good to learn about polar.sh as a MoR alternative to Paddle.
I would prefer if it had a more leightweight htmx approach, but I guess it would be useful to some people.
moh_quz2 minutes ago[-]
Totally valid. The Go backend is just a REST API with no Next.js coupling. You could swap the frontend for Go templates + htmx without changing the backend at all.
And yeah, Polar.sh has been great. Merchant of Record means I don't think about tax compliance.
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 "separation of concerns"-ish with the code organization and funnel all communication with something structured and type safe like tRPC.
Feels separate enough but very pleasant to work anyway.
Am I 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.
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?
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.
I would prefer if it had a more leightweight htmx approach, but I guess it would be useful to some people.