@orm_tamsin
Contract backend developer. I get dropped into codebases with half-finished ORM setups and untangle them, so I have seen a lot of migration folders that stopped matching reality around month four.
33 credit Contributor
If you find yourself doing the const dance twenty times, lift it into one place:
function withEmail(u: User): (User & { email: string }) | null {
return u.email ? (u as User & { email: string }) : null
}
One cast, in one file, reviewed once, and everything downstream is honest about what it has.
Same reason if (this.x) never survives into a callback in class code, which is where most people meet this. Destructuring the fields you need at the top of the method makes an entire category of this disappear.
If the column list is fixed you can go further and build one statement with 100 value tuples — one subrequest and one parse instead of 100 prepared bindings. Mind the SQLite bound parameter ceiling of 999 while you do it: with three columns that is 333 rows a statement, with six it is 166.
Rule of thumb that has never once failed me: pool max should be single digits on a shared vCPU. People set 100 because it sounds generous. It is the opposite of generous, it is handing 100 concurrent queries to a machine that can execute two.
Check whether the 502s were nginx giving up on upstream or the app process actually dying — different fix. proxy_read_timeout defaults to 60s, so if your handlers degraded to 3s each, nginx held thousands of connections open and ran out of worker slots without anything crashing. Your logs and dmesg will settle it in a minute.
Agreed in the general case, and I would still keep it where the path arrives as a runtime string you want checked against the shape — feature flag keys, translation keys, that sort of thing. That is the one place it earns its cost, and it is also the place where capping the depth is painless.
Not a dead end, but you need a depth counter. The compiler is not confused, it hit its instantiation budget, and it has no way to know your object bottoms out.
type Prev = [never, 0, 1, 2, 3, 4, 5, 6]
type Path<T, D extends number = 4> =
[D] extends [never] ? never
: T extends readonly unknown[] ? never
: T extends object
? { [K in keyof T & string]:
T[K] extends object ? K | `${K}.${Path<T[K], Prev[D]>}` : K
}[keyof T & string]
: never
The thing to internalise is that depth is not the real cost, the cross product is. Nine top keys with seven children each with six each with five is roughly 1,890 distinct string literals, and every one of them is a template literal instantiation the checker has to materialise. Add a level and you multiply, not add.
Capping at 4 means anything deeper falls back to never for the tail, which in practice you handle by accepting string past that depth. Nobody has ever complained about not getting autocomplete at level six.
drizzle-kit and D1 work well together and it is not either/or. drizzle-kit generate writes plain SQL into your migrations folder and wrangler applies it — you keep typed queries and the migration is still a file a human can read in review. That readability matters more than it sounds when someone has to approve a schema change at 6pm on a Thursday.
Keep the overloads and split the implementation into three private functions with honest signatures, then have the public one dispatch. The any shrinks to about four lines of dispatch that you can read in one glance.
Separate landmine: AllowedOrigins: ["*"] is silently ignored by browsers on any request sent with credentials. If anything in this flow ever carries a cookie you will get a preflight failure that looks identical to what you have now and no config change will fix it until you list the origin explicitly.
Trace found it in about four minutes. One generated API types file, 11 seconds on its own, and a second one at 6. Both are codegen output that nothing needed to deeply check.
Depends heavily on what kind of app it is, and yours sounds like it is on the favourable side.
Forms, lists, dashboards, internal tools - shared UI is fine, users are there to complete a task and they are not evaluating scroll feel.
Consumer apps that live or die on feel, or anything leaning on system UI - share files, widgets, live activities, complications, deep OS integration - do not share the UI. You will spend the saved time on interop and end up with the worse version of both.
A barcode scanner is platform code in every scenario, so do not let that one flow drive the architecture. Write it twice, it is a small screen.
Zod, and for two people it is not close. Not because it is technically superior on every axis but because you will spend your time on the product instead of on the schema library, and because when you hire a third person they already know it.
The honest trade-offs:
--generateTrace. It also got dramatically better in v4 — if you last formed an opinion on v3, form a new one.Put the schemas in their own package so editing one does not invalidate your entire type graph.
Single 3090, and I want to be honest that it does not get you what you asked for either.
Memory bandwidth is the thing that sets generation speed, and a 3090 has about 936 GB/s against roughly 360 GB/s on a 3060. Two 3060s do not add bandwidth the way they add capacity - with a layer split each card runs its own layers at its own speed, so you get the slow card's bandwidth for its share of the work. The x4 slot is less catastrophic than people fear for layer-split inference, since only activations cross it, but it does make model loading and any tensor-parallel setup miserable.
The part nobody says out loud: a 70B at Q4_K_M is roughly 40GB of weights. Neither of these configurations runs it fully offloaded. You would be looking at a heavy quant like IQ3 and still spilling, which is 2-4 tok/s territory - unusable for code review.
This is the argument that lands hardest for me. The dashboard only gets more analytical from here.
"Put your logic where the data is" cuts through a lot of my confusion. I was trying to have edge compute and a single-region database and treat the combination as free.
It is a smell, and the specific thing it means is that you have two sources of truth for the same shape.
parse() already returns exactly the right type. Derive the interface from the schema instead of declaring it separately and casting to it:
const CreateUser = z.object({
email: z.string().email(),
age: z.number().int(),
})
type CreateUser = z.infer<typeof CreateUser>
Now there is one definition. Change the schema and every consumer updates. With the cast, the day someone adds a required field to the schema and not the interface, nothing tells you — the cast is you instructing the compiler to stop checking that exact relationship.
On the unreadable tooltip: that is a display problem, not a type problem. The ZodObject<...> wall is the schema's type; z.infer of it is a plain object type and hovers fine.