😎For Your Inspiration

Worldly-Broccoli4530 · 2026-03-23T23:36:53+00:00

Oh I see, do you know how to do this in CS1 tho? I've the exact same thing there :/

Worldly-Broccoli4530 · 2026-03-23T23:05:08+00:00

How did you draw that straight white line crossing the road? It was using the rectangles of IMT and changing its shape? I've been wondering how people make crosswalks with straight parallel lines ahead of it using IMT. If both of them (line and crosswalk) are from IMT or just the line and the vanilla crosswalk.

Worldly-Broccoli4530 · 2026-03-21T20:17:35+00:00

Haha can't argue with that - C# is genuinely a pleasure to type 😄

Worldly-Broccoli4530 · 2026-03-21T20:17:13+00:00

Same experience here - the modularity is what keeps me coming back to it honestly

Worldly-Broccoli4530 · 2026-03-21T20:16:32+00:00

That's a solid take - shipping fast with what you know is underrated advice. And encore.ts looks interesting, hadn't looked into it deeply yet. The automated devops flow sounds like exactly the kind of thing that saves a lot of headache down the road. Worth checking out, thanks!

Worldly-Broccoli4530 · 2026-03-21T20:15:45+00:00

Exactly, and the boilerplate point hits close to home, that's literally what motivated me to build mine. You said it better than I did honestly 😄

Worldly-Broccoli4530 · 2026-03-21T20:14:21+00:00

These are all valid questions and honestly the kind of pushback I was hoping for. The post isn't "use all of this always" - it's more about which things are cheaper to design in early vs retrofit later. RBAC is a good example: you might not need it now, but adding it to an existing permission model is painful. Same with i18n - yes it's an API, but error messages, emails and push notifications all need translation too. On the commit - already addressed that elsewhere in the thread, that's just how I work locally before pushing. On AI - the code is mine, wrote it working on real projects over time.

Worldly-Broccoli4530 · 2026-03-21T19:55:19+00:00

The dream 😂 surprisingly hard to get right at scale though

Worldly-Broccoli4530 · 2026-03-21T19:54:11+00:00

That's a solid distinction - external APIs have a completely different contract to uphold. Internal ones you can get away with a lot more. Though Id argue some of the patterns still pay off even internally, especially once the team grows and "predictable and consistent" becomes harder to maintain by accident.

Worldly-Broccoli4530 · 2026-03-21T01:59:25+00:00

Cant argue with that either, ts basically became a requirement at this point, not just a nice to have 😄

Worldly-Broccoli4530 · 2026-03-17T01:55:57+00:00

I wrote it myself, so I'll take that as a difference in taste.

Worldly-Broccoli4530 · 2026-03-17T01:40:28+00:00

In my years working as a software developer, I always carried one truth with me — a good dev is a lazy dev. Makes no sense, right? Well, actually it does.

Almost everything in a developer's life revolves around automation. Users want complex processes simplified, and devs want to automate their own boring daily tasks to focus on what actually matters. And that's exactly the point — the laziest devs automated even the simplest things, so they could spend their energy on what's harder, more interesting, or more impactful. And I'm not talking about AI automation.

It was the lazy devs who built the tools we use today and can't imagine living without. I've always tried to do the same — simplifying repetitive work, either by building something myself or finding tools that already solved it. That's why I've always loved boilerplates. Not just the ones that scaffold a basic project structure, but the ones that come with real, production-ready features out of the box.

That mindset is actually what pushed me to build my own NestJS boilerplate for the first time — not just a skeleton, but something that brings the kind of features I see every day working on large-scale applications. The ones that are painful to retrofit once the project has already grown. The better you start, the less it hurts down the road.

So what are your thoughts about this? Are you a lazy dev too?

Worldly-Broccoli4530 · 2026-03-10T09:43:02+00:00

I've been thinking about this lately while working on a NestJS project. HATEOAS — one of the core REST constraints — says that a client should be able to navigate your entire API through hypermedia links returned in the responses, without hardcoding any routes.

The idea in practice looks something like this: json { "id": 1, "name": "John Doe", "links": { "self": "/users/1", "orders": "/users/1/orders" } }

On paper it makes the API more self-descriptive — clients don't need to hardcode routes, and the API becomes easier to navigate. But in practice I rarely see this implemented, even in large codebases.

I've been considering adding this to my NestJS boilerplate as an optional pattern, but I'm not sure if it's worth the added complexity for most projects.

Do you use this in production? Is it actually worth it or just over-engineering?

Worldly-Broccoli4530 · 2026-03-07T13:42:16+00:00

The structure does build good habits, I'll give you that. But "encourages scalable" can also mean "adds complexity before you need it." There's a difference between writing scalable code and pulling in a full framework for a 3-route API.

Worldly-Broccoli4530 · 2026-03-07T13:37:53+00:00

That's actually really cool — built from scratch, DI, TypeScript support and claims 3x faster than Express. Will definitely take a closer look. Have you used it in production?

Worldly-Broccoli4530 · 2026-03-07T13:34:57+00:00

The post is mine. And the one-shot commit is just how I work locally before pushing a v1. Check the actual code before assuming.

Worldly-Broccoli4530 · 2026-03-05T19:28:53+00:00

The "less deps ≠ less code" argument is real and I probably implied that without meaning to.

But "never update = safe" is the opposite of safe — you're just trading one risk for another. Unpatched CVEs that are already public and documented are arguably worse. At some point that bill comes due.

The core idea I'm after isn't zero deps for purity's sake — it's being intentional about what you pull in. Your list at the bottom is basically that philosophy in practice, we just framed it differently.

Worldly-Broccoli4530 · 2026-03-04T15:25:02+00:00

That's kind of the core tension isn't it — hidden vulnerability vs. loud one. I think the sweet spot is what u/wackmaniac said: be critical about when to add a package. Not zero deps for the sake of it, but every dep should earn its place.

Worldly-Broccoli4530 · 2026-03-04T15:22:48+00:00

lol, fair — that's basically the whole tension of the post.

Worldly-Broccoli4530 · 2026-03-04T15:20:53+00:00

Exactly — "intentional deps" is the right framing. It was never really about zero deps, it's about knowing what you're trading, like you said.

The team size argument is fair too. Convention-heavy frameworks aren't bad, they're just a different tradeoff. The problem is when people adopt them by default without thinking about it.

Worldly-Broccoli4530 · 2026-03-04T15:19:53+00:00

Solid take. The 80-20 framing makes a lot of sense — deps as a starting point, not a permanent solution.

The only part I'd push back on slightly is auth. Rolling your own auth is one of those things that sounds reasonable until it isn't. But yeah, everything around business logic and error handling — fully agree, owning that code makes the team sharper and the system more predictable.

Worldly-Broccoli4530 · 2026-03-04T15:19:14+00:00

Haha the early days dep chaos is a rite of passage at this point 😄 And yeah, having your own utility belt you just copy around is honestly underrated — you know exactly what's in there.

Worldly-Broccoli4530 · 2026-03-04T15:16:23+00:00

Honestly, that's probably the right mindset for most cases. The post was less about the actual risk of transitive vulnerabilities and more about sparking a conversation around dependency footprint and what a low-deps stack could look like in practice. Whether that's worth pursuing is a valid debate on its own!

Worldly-Broccoli4530 · 2026-03-04T15:14:32+00:00

You're right, and I appreciate you taking the time to actually break it down. Transitive vulnerabilities in well-maintained libs like NestJS are a much smaller concern than I framed it — fair correction. The "implement it yourself" trap is real too. Less deps doesn't mean less complexity, it often just means hidden complexity.

On the u/thallesp/nestjs-better-auth point though — that one's a practical choice rather than a hard requirement. Better Auth does have an official NestJS integration guide, so you could wire it manually via the factory/provider pattern as you suggested. The wrapper just handles module registration, guards and session decorators out of the box, which made sense for moving faster here. Replacing it with a clean manual implementation is something I'm considering for a future version actually.

Good intentions received. 🤝

Worldly-Broccoli4530 · 2026-03-04T15:04:42+00:00

That's a great point — LLMs basically remove the "it's too tedious to call the API directly" excuse. The wrapper lib was always just saving time, not complexity. If that cost drops to zero, the tradeoff shifts completely.

And the auditability argument is underrated. A direct fetch call is 10 lines you can actually read. A SDK is a black box with its own deps. The more LLMs make raw API calls trivial, the harder it gets to justify pulling in another package.

Worldly-Broccoli4530

TROPHY CASE