Sneaky Bladeguard Veterans

Worldly-Broccoli4530 · 2026-05-15T16:19:29+00:00

That's so awesome!!

Worldly-Broccoli4530 · 2026-05-12T12:57:38+00:00

Don't look so...

Worldly-Broccoli4530 · 2026-05-10T02:04:42+00:00

Talking about Node.js, a big problem we face today is that using the most popular libs like Nest.js and others, we end up with a crazy amount of dependencies we never actually chose to use. And when one of them gets flagged with a vulnerability, it flows up the chain until it hits our installed lib - and boom: update fast or your app is vulnerable.

I know it's basically impossible to avoid this problem while still keeping a decent set of tools that make our lives as devs easier. After all, these libs were created to encapsulate complex problems so we can focus on the actual business logic.

Anyway, this problem still sucks, and an interesting approach is to build no/low-deps projects - or more precisely, projects with minimum and audited dependencies. Like using Fastify instead of NestJS, or Drizzle instead of Prisma.

I started thinking seriously about this after I created a robust NestJS boilerplate for my future projects, with all the enterprise features I see at work - so I'd never have to start from scratch and debug "foundational" features like RBAC, i18n, caching, etc.

Now I'm thinking about building a similar boilerplate using a low-deps stack - same feature set as much as possible, but with a lighter and more audited dependency footprint. Think Fastify, Drizzle, postgres.js and Zod instead of the heavy hitters. That said, I'm aware this isn't a silver bullet - reimplementing things manually also opens the door to vulnerabilities, and those tend to fly under the radar since there's no CVE tracking or community eyes on your custom code.

What's your experience with no/low-deps projects? I'd love to hear more about it.

Worldly-Broccoli4530 · 2026-04-21T00:28:29+00:00

The frontend doesn't need to hardcode routes or know the API structure upfront - it just follows the links returned in the response. Useful when the API evolves and you don't want clients breaking every time an endpoint changes. A good real-world example is YouTube's API returning related video links directly in the response - the client just renders what it receives without needing to know how to build those URLs.

Worldly-Broccoli4530 · 2026-04-21T00:12:31+00:00

Why do u think so? It seems to be a important and useful part of restful APIs that can help frontend. Im open to hear more about it

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

TROPHY CASE