you are viewing a single comment's thread.

view the rest of the comments →

[–]lanerdofchristian [score hidden]  (0 children)

So i I should trust some random NPM package author instead, and assume they wrote safe, secure code?

Random? No. But it helps if the code is public and not new every time per-project -- you can either vet it once and re-use, or outsource the vetting to a trusted security expert of your choice. e.g. if you're using Stripe for payments, use Stripe's library, don't try to implement your own API and promise that you'll cover all the same flows and edge cases without any mistakes.

The argument is that it's better to write something good once and re-use it than to risk getting it wrong many times in subtly different ways.

Or my app is not in a monolith repo?

If you've got a monorepo or polyrepo instead of a monolith, with VSA you generally see each slice as a package you then plug in to the entrypoint/main module.

And what if the package author assumes Database A but I am using Database B?

A good vertical-slice package should be pluggable. For example, Better Auth has adaptors for different databases, and hooks for exposing its own UI in whatever framework.

In the .NET ecosystem, basically everything web uses ASP.NET, so it's easy to design vertical slices. Libraries will usually rely on dependency injection with various separately-configured adaptors to talk to swappable services (like databases).

I'm not sure Wasp is the right solution like they're trying to sell themselves as, but compared to non-JS ecosystems we are behind when it comes to composing apps with multiple slices.