Hacker News Reader

Comment by CharlieDigital | Hacker News Reader

Big problems for APIs though because TS types disappear at runtime.

So now you need to add in Zod or Valibot as well to validate your types. If you have view models and DTOs, then you add more Zod. Might as well use a statically typed language?

Working with OpenAPI is much easier when you already have a static type system.

How about database transactions? Ran into an interesting issue this week. In a .NET world, every ORM can participate in an ambient transaction because everyone uses System.Transactions. Not the case in Node because there's no such thing.

Would not build backends in TS except for true microservices. The ergonomics of a Nest.js vs .NET Web API are night and day.

View on HN

> How about database transactions? Ran into an interesting issue this week. In a .NET world, every ORM can participate in an ambient transaction because everyone uses System.Transactions. Not the case in Node because there's no such thing.

I mean you could say the same thing about TypeScript - if your entire stack is TypeScript then there's no need for the type validation either.

Even if your entire stack is TS, you still need validation because the submitted data from an external interface (API call) might not be valid.

You can't just accept any JSON payload and expect it to be valid.

In Java or .NET, it will fail at serialization when the runtime tries to map it to a static type (automatic). This is not the case at runtime with JS (because at runtime, it's no longer TS). Thus you need a Zod or a Valibot to ensure the incoming payload is actually valid by describing the valid types (even if your whole stack is TS at dev time because schema mismatches are a runtime problem).

.NETs System.Text.Json does the mapping and validation using either reflection or AOT generated serializers transparently and automatically because it has static types.

Yes .NET's built in SDK is larger than Node.JS's. I'm not sure what your point is exactly. As you stated just use a validation library if that's necessary. It generally is not though, you can cast the entire output to a type in TypeScript, of course this isn't validation, but it's generally good enough.

Of course if you’re writing a full stack app you can share everything, validating the front and backend with the same code. Clearly that would be a strange thing to hold against .net, similar to the lack of built in validation in typescript.

You double up your work. What you really wanted all along are static types.

not necessarily, and in plenty of programming languages static types do not give you validation for free, and in the case of .net you still have to call something else. it's no different than just using zod, other than the fact that it's built in.

if you're using typescript in the front end, seems double to even bother to introduce .net, when typescript and node is fine for the backend too.

    > [amazingamazing 31 minutes ago] I mean you could say the same thing about TypeScript - if your entire stack is TypeScript then there's no need for the type validation either.

I think that if you're here trying to make the case that if your whole stack is TS, you don't need to validate your incoming data, then you probably haven't built a system of consequence where the data actually matters and none of this discussion really matters; you have no context. Go ahead and try to `curl` some nonsense data to any of your TS endpoints and see what happens at runtime without validation.

I'm not really sure what your point is. you can add validation in node.js, just like you can with .net.

also, with curl you'd use isomorphic type safety, or just know what you're expecting and hard code the types per inputs, trivial with typescript.

anyway, I'm done here since this conversation is going in circles.

I think CharlieDigital's point is that a bad payload will fail right at the serialisation boundary in case of .NET. We know the problem right there. Now we only need to fix the bad payload.

For TypeScript with only types and without validation, a bad payload gets through, and there is no telling where in the workflow it will explode. This could waste more time and developer resources in debugging.

Again this isn’t an inherent property of .net, you have to add validation. There are plenty of ways to do this in node so the point is moot.

Here is a .NET web API

    var builder = WebApplication.CreateBuilder(args);
    var app = builder.Build();

    app.MapGet("/{userId}", (int userId) => userId);
    app.Run();

See `int userId`? If I call this API with `http://localhost:5123/asdf`, I will get an error because the types don't match. If I call this with `http://localhost:5123/1234` it will work fine. The same would be true if I required a class `User` here. The router is able to introspect the type at runtime to determine if the types match; both basic types like this as well as complex types using the built-in serializer. It is built in.

I've put it into a short clip for you: https://imgur.com/a/WNbGUQD

I’m not sure why you’re so obsessed with this. You can do the same thing with any validation library in nodejs. Your exact example is possible by integrating any validation library of your choosing into a nest js route pipe. In particular primitive type validation is built into nestjs anyway

The fact that it’s built in is neat but not really important. Most people are not making thousands of toy apps. If the necessary they will integrate and move on.

There are more compelling reasons to use .net than this.

The issue is that this sort of validation boilerplate shouldn't have to be written. The framework should be able to figure it out from the HTTP handler declaration. I suspect this is why FastAPI got so popular in the Python world.

IMO, a lot of the JS world seems mentally fixated on express.js-levels of abstraction still. Anything more is viewed as "magic" and viewed as suspect because it requires learning.

The irony is that the "learning" just gets applied elsewhere; there are certain foundational building blocks that I think every language and platform needs once you start building "serious" applications.

Reply on news.ycombinator.com