81–90 of 236 posts
How did this kind of syntax become so popular? I think express is the first to do the scheme of: app.handleGet("/route/goes/here", (req, res) => { }); Which seems like it's useful for making really quick and dirty micro-services (nano-services, even), but I still vastly prefer the more declarative and modular schemes of bootstrap or asp.net: // Middleware automatically routes "/Foo" to FooController [Controller] publ…
How did this kind of syntax become so popular? I think express is the first to do the scheme of: app.handleGet("/route/goes/here", (req, res) => { }); Which seems like it's useful for making really quick and dirty micro-services (nano-services, even), but I still vastly prefer the more declarative and modular schemes of bootstrap or asp.net: // Middleware automatically routes "/Foo" to FooController [Controller] publ…
You're also doing more in your second example. You can still do service injection in JavaScript.
Forcing a panic when 2 routes are matched seems counter intuitive to me (versus, idk, every other web framework which uses the first-to-be-registered route that matches). Are there go-specific reasons for that? The edge case of "you might register HTTP routes in a bunch of places and it's harder to find that if multiple routes match" seems like something that be worked around with tooling. I've (ab)used the behavior…
> Are there go-specific reasons for that? In general , the reason you use a compiled / typed language like golang at all (instead of, say, perl) is to "left shift" your bugs: A bug caught when you first spin up your application is better than a bug caught after a corner case acts up in the wild, and a bug caught when you compile is better than a bug caught when you first spin up your application. I recently ran a cro…
Earlier quoted context omitted.
What common use-cases does it not support?
The `/foo/bar` and `/foo/*` use-case, where you want the first to go to a special page and the latter to go to some regular page. Perhaps the former is hard-coded/static and the latter looks up some URL parameter in a database. You can of course always implement this within `/foo/*`, but then you're implementing your own URL routing and working around the framework rather than working inside the framework. This feels…
Earlier quoted context omitted.
What common use-cases does it not support?
The `/foo/bar` and `/foo/*` use-case, where you want the first to go to a special page and the latter to go to some regular page. Perhaps the former is hard-coded/static and the latter looks up some URL parameter in a database. You can of course always implement this within `/foo/*`, but then you're implementing your own URL routing and working around the framework rather than working inside the framework. This feels…
> Longer patterns take precedence over shorter ones, so that if there are handlers registered for both "/images/" and "/images/thumbnails/", the latter handler will be called for paths beginning with "/images/thumbnails/" and the former will receive requests for any other paths in the "/images/" subtree.
How did this kind of syntax become so popular? I think express is the first to do the scheme of: app.handleGet("/route/goes/here", (req, res) => { }); Which seems like it's useful for making really quick and dirty micro-services (nano-services, even), but I still vastly prefer the more declarative and modular schemes of bootstrap or asp.net: // Middleware automatically routes "/Foo" to FooController [Controller] publ…
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 JavaScript.
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)
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.)
Earlier quoted context omitted.
There's nothing "black magic" about them; they're very well documented features in Java, C#, and Python. They're officially experimental in Typescript but they're so heavily relied upon I can't imagine them getting deprecated
> // Middleware automatically routes "/Foo" to FooController I don't know why, but I truly do not like this. So if I create a "HelloController" class does the middleware just start automatically routing "/hello" to it?
Earlier quoted context omitted.
The `/foo/bar` and `/foo/*` use-case, where you want the first to go to a special page and the latter to go to some regular page. Perhaps the former is hard-coded/static and the latter looks up some URL parameter in a database. You can of course always implement this within `/foo/*`, but then you're implementing your own URL routing and working around the framework rather than working inside the framework. This feels…
I understood what you were saying but it might be easier to read if you escaped the * characters.
Earlier quoted context omitted.
> Are there go-specific reasons for that? In general , the reason you use a compiled / typed language like golang at all (instead of, say, perl) is to "left shift" your bugs: A bug caught when you first spin up your application is better than a bug caught after a corner case acts up in the wild, and a bug caught when you compile is better than a bug caught when you first spin up your application. I recently ran a cro…
Wouldn’t the “left-shift” be a compiler error instead of a panic?
Earlier quoted context omitted.
There's nothing "black magic" about them; they're very well documented features in Java, C#, and Python. They're officially experimental in Typescript but they're so heavily relied upon I can't imagine them getting deprecated
>There's nothing "black magic" about them; they're very well documented features in Java, C#, and Python. Sure there is. It's metaprogramming. Anyone in the world who can read code can understand this immediately: app.get('/', (req, res) => { res.send('hello world') }) Throw decorators in the mix, and now I need to learn exactly what this specific environment is doing with those annotations. I have absolutely no way…
> And you're now also stuck with vendor lockin to whatever framework/compiler was using them
I don't understand. If you choose a web framework, you are locked in to developing things in that framework from now on. In what world do companies try to change web frameworks without having to change any of the underlying code? In what world would they want to do so?