3 ms·

You're joking, right? How is the second example better in any way? You're also doing more in your second example. You can still do service injection in JavaScr

• shortrounddev2 3y ago
  The 2nd example: 1. Uses declarative routing, which looks better and makes more sense than running a function to handle routing (e.g, you read it as "There is a handler named GetFoo living within the Foo controller that exists at the base route"). Declaration is more important to the end user than implementation when creating an interface. It also allows you to export these classes to a different Main method which can generate documentation for you without having to even run the HTTP server (the declarations can be picked up using RTTI and not actually having the runtime server activated). You can also add named parameters to the routes and then add them to the body of the handler with their proper types, e.g: [HttpGet("/{id}")] public ActionResult GetFoo(int id) And that input validation is handled automatically. Named parameters exist on a lot of these frameworks as well, but Javascript doesn't provide static typing so it's not a good language for writing a backend in 2. Handles input validation under the hood or through middleware so you don't have to manage it in the controller body 3. Can also handle user auth under the hood using attributes so you don't have to handle it in the controller body 4. Uses middleware to handle routing in a predictable way (e.g: the name of the controller is the name of the route by default) 5. Uses class-based controllers to encapsulate the services available to the controller through the constructor, and also helps pair a single model to a single controller for making really simple RESTful interfaces You can also define a custom controller interface or abstract class which provides a bunch of default functionality that you commonly re-use (e.g: ApiController with some built in response wrappers/handlers for error codes, etc.)
  • neonsunset 3y ago
    This is straight up wrong. Documentation can be generated from either pattern. It can also do authorization if you wish so (middlewares, attributes, you can do it however you want). We get it, you like the controller pattern, but please do not post incorrect information to prove the point.
    • shortrounddev2 3y ago
      Try actually reading this time. I never said that middleware didn't exist in other frameworks, I said you can control that middleware using attributes. Do not accuse other people of being disingenuous because you didn't read something right
  • avianlyric 3y ago
    > And that input validation is handled automatically. Named parameters exist on a lot of these frameworks as well, but Javascript doesn't provide static typing so it's not a good language for writing a backend in God the number of bugs and bad practices I've had to deal with and work around do to auto-magic casting of url segments, or JSON blobs into language native types, is too damn high. Auto input validation based on function parameter types sounds good, until you think about for more than a couple of seconds and start to realise type primitives definitions vary significantly between languages. Using them for input validation just means exporting your languages type primitives into your API, with zero consideration of if that's a good idea. The classic example of this is people using the `int` type for `id`s just because the IDs happen to contain only digits. Ignoring the fact that identifiers aren't numbers (performing numeric operations on them doesn't make any sense), but because you've now blindly exported the `int` type into your API, you also export nastiness like precision (try preserving leading zeros with your `int` type) and rollovers into your API. Two things that make zero sense when dealing with identifiers, and two things that often change depending on the exact platform your software is running on.
  • dimgl 3y ago
    You're making these statements as if the example you're presenting is the only one of its kind that has these properties. It's simply not the case. You can use middleware in other frameworks just as well. You can do input validation in other frameworks just as well. You can also class-based route handler encapsulation in other languages just as well. And I'd argue it looks _significantly_ cleaner than whatever is going on in ASP.NET land. I'd really encourage you to explore other languages. If you're one of those "JavaScript is bad" people, there's plenty of others: Go, Ruby, Python... I'm surprised to be seeing this kind of comment on Hacker News to be honest.
• shortrounddev2 3y ago
  > You can still do service injection in JavaScript I know that angular is really good at this, but I'm not sure what pure js frameworks would allow a service to be defined as an interface first, and then injected into the constructor of a controller (or even a handler function) based on the implementation method selected somewhere else. I just haven't seen it happen.
  • nicoburns 3y ago
    tsyringe is a popular library that does this in TypeScript
    • shortrounddev2 3y ago
      Yeah I use nestjs for my backend at my company and it also has a good DI framework, but it depends on typescript interfaces to work well