11–20 of 40 posts
Oh boy another template shipped in a single commit; complete with "For now, do this" and "In production you would do this" comments
I stripped out the business logic and keys, then pushed it as a clean starting point.
The "in production you would" comments are guides for where to add your own config.
Single commit because I didn't want my app's git history in an open source repo.
Earlier quoted context omitted.
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.
Thanks for the answer! I've hit those tipping points myself in exactly the same scenarios (OCR and AI). For me, ends up being hacky or just decoupled (independent job runners). Makes sense to have a proper monolith backend for these. Congrats on the launch again!
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.
[flagged]
If you need anything don’t hesitate to reach out, you can find my info in the repo
A thing to consider would be to make it easier (or perhaps bake it in) to separate out parts of the app into a separate origin. Something that would be good for pretty much any SaaS app would be to separate the IAM out (could still embed it with an iframe) - this allows you to keep a fairly tight security policy for the IAM stuff and a more lax one for the rest of the app. Kinda how Google separates out accounts.google.com.
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.
This is cool - Whenever I have a new idea for a thing I spend too much time writing boilerplate IAM and backend stuff, taking away time that could be spend on actual business logic. Thought about packaging the boilerplate stuff up before, never gotten around to it. Glad you did! A thing to consider would be to make it easier (or perhaps bake it in) to separate out parts of the app into a separate origin. Something th…
Your IAM separation idea is interesting. Separate origin for auth would tighten the CSP significantly. The backend is already modular, so spinning the auth service into its own container with a stricter policy is doable. Worth exploring. Would you mind opening an issue on the repo so I don't lose track of this?
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.
PRs welcome if anyone wants to help out
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 of Next.js (React). I chose this even though I'm new to vue cause I saw the open source components and templates here [2] (especially the dashboard template: [3]) and was convinced.
I'll definitely check out your repo as inspiration.
[2]: https://ui.nuxt.com/