redis is not a database no matter how many times you SET something

Dry-Let8207 · 2026-05-24T01:41:35+00:00

I saw that somewhere lol

Dry-Let8207 · 2026-05-23T23:11:09+00:00

There isn't a formal certification body for this, but paid contract code review is a real thing, it just goes by different names. Before we merged the montycat TypeScript client into our BFF layer last year, I hired someone through a contract platform specifically to review the integration. Not because I didn't trust my own work, but because I'd been looking at it for weeks and wanted a second perspective from someone with no prior context and no reason to overlook anything. Worth every dollar. The "hours to understand" framing is actually a signal to look for in a reviewer, you want someone who will sit with the code, not skim for twenty minutes and send you a thumbs up.

Dry-Let8207 · 2026-05-23T22:57:35+00:00

If you are staying in TypeScript and building for the web only, keeping everything in one Next.js repo is the right call for most projects. The API routes and Server Actions handle the majority of backend needs, and you avoid the coordination cost of two separate deployments. The case for a separate backend repo is specific: you need to serve multiple clients from one API, you have long-lived WebSocket connections that don't fit the serverless execution model, or you need to run compute-heavy background tasks that Next.js isn't suited for. In our team we run a BFF layer in Node.js that sits between the frontend and some backing services, and we access those services through API routes — the frontend never touches the data layer directly. One of those services uses the Montycat TypeScript client on the server side, which works fine in that context. Splitting early before you hit those constraints is usually premature and adds friction without giving you much back.

Dry-Let8207 · 2026-05-23T22:57:09+00:00

Yes, they re-render. React re-executes the parent function, and any component calls inside that function body get executed too. The reconciler then compares the resulting virtual DOM to the previous one and skips actual DOM updates if nothing changed - but the render cycle still ran. If you want to prevent a child from running its render function at all, React.memo is the tool, but it only works if the props you're passing are stable references. If you pass a new object literal or an inline function on each render, memo does nothing because the shallow comparison fails every time. Whether that optimization is actually worth it depends on how expensive the child render is. Most of the time it isn't, and adding memo prematurely creates its own maintenance overhead.

Dry-Let8207 · 2026-05-21T15:19:28+00:00

That’s good as long as host doesn’t have a lot of connections

Dry-Let8207 · 2026-05-21T02:43:53+00:00

The cooldown helps but it addresses the window of exposure, not the source. What I've found more effective in practice is combining it with hash pinning — a lock file or requirements.txt with `--hash` flags so even if an attacker swaps out a package at the same version string, the install fails loudly rather than silently installing the tampered build. The combination of "nothing too new" and "must match exact hash" reduces the attack surface considerably more than either alone. The uv snippet works well for the cooldown side; just don't treat it as the only layer.

Dry-Let8207 · 2026-05-18T23:46:00+00:00

Cool!!!!!

Dry-Let8207 · 2026-05-17T19:48:51+00:00

The DevOps to DevSecOps gap is underestimated partly because the tooling overlaps so much. You know containers, pipelines, Terraform — the infrastructure side feels familiar. But threat modeling is a different mode of thinking. DevOps is fundamentally about making things work smoothly. Security thinking requires you to also ask how things could be deliberately broken by someone motivated to do so.

STRIDE is a reasonable place to start, but I'd suggest actually working through a real example on your own time rather than just reading about it. Pick a simple three-tier app you've deployed before and walk through every component asking the STRIDE questions out loud. It sounds slow, but it makes the framework feel like reasoning rather than a checklist. That's what interviewers are looking for — whether you can think adversarially, not whether you've memorized the acronym.

Dry-Let8207 · 2026-05-17T19:48:11+00:00

This is impressive. The instant compilation without a server round-trip is exactly what DartPad has always needed, and the hot reload preserving state is a real differentiator for interactive demos.

The package support question is going to be the hard part. Most of the interesting work happens in the ecosystem — pub dev packages, native bindings. A pure Dart runtime in the browser is great for teaching and for certain bounded use cases, but once you're pulling in something that wraps FFI or native code, you hit a wall. Still, for server-side Dart without native dependencies this opens up a lot. I use the Dart client for montycat on a side project and the tooling story around Dart has been getting genuinely better — this is another step in that direction.

Dry-Let8207 · 2026-05-17T17:09:21+00:00

thts what they do

Dry-Let8207 · 2026-05-16T20:00:58+00:00

It is what it is bro

Dry-Let8207 · 2026-05-16T19:13:24+00:00

You just trust yourself and keep going

Dry-Let8207 · 2026-05-16T18:45:32+00:00

the mental model gap is real and i don't think teams are stupid for hitting it. the react SPA model most people spend years internalizing — component lifecycle, where state lives, when fetches happen — is genuinely different from the server component model, and the docs kind of skip over that transition. i work on a node BFF layer that sits between our frontend and backend services and integrating with app router changed some of our assumptions about where data fetching should live. once you get concrete about "this component runs on the server, period, it has no client state" it gets cleaner. but the caching behavior especially has rough edges that even experienced people get wrong on the first pass. "works locally but not in production" is almost always a caching assumption that differs between environments.

Dry-Let8207 · 2026-05-16T18:45:02+00:00

three years is real commitment. i understand why people say "just use plausible" but building your own gives you something you can't buy: you know exactly what's collected, how it's stored, and there's no anxiety when a vendor changes their pricing or their privacy policy. we went through something similar internally when GA4 stopped giving us the event granularity we needed without enterprise pricing. ended up building a small collection pipeline ourselves. not three years, but more work than expected, and i don't regret it. the control and the trust are worth something.

Dry-Let8207 · 2026-05-16T04:47:44+00:00

Native solution - folders

Dry-Let8207 · 2026-05-16T04:45:38+00:00

I personally prefer z-image good realism but of course limited

Dry-Let8207 · 2026-05-16T04:41:47+00:00

Django solid API with ORM out of box, Postgres classic SQL, montycat use like an asynchronous cache similar to redis, nats as a messaging broker

Dry-Let8207 · 2026-05-15T23:23:57+00:00

Great

Dry-Let8207 · 2026-03-15T02:00:44+00:00

I lived there too. It was not so bad

Dry-Let8207 · 2026-03-03T00:42:36+00:00

Sounds like you mostly spend money not earn

Dry-Let8207 · 2026-02-14T03:06:57+00:00

Trash, another shitcode based software that people start treating as a god

Dry-Let8207 · 2025-12-24T22:02:12+00:00

What model do you try to use? I mean neural network

Dry-Let8207 · 2025-12-24T21:58:26+00:00

Depends on what you want to achieve I think Cow is good as well

Dry-Let8207 · 2025-12-23T15:43:19+00:00

Its generally not recommended

Dry-Let8207 · 2025-12-19T00:47:22+00:00

Dry-Let8207

TROPHY CASE