Proposal: Middleware concept about grapevine-legacy

[tekhedd]

Could be very useful. Pluggable auth is the only reason I would personally care about middleware. It wasn't difficult to do without support; the LOC won't change for the bulk of the app. If your app is well organized you can do security using prefix patterns, but otherwise it could be inefficient (with a lot of redundant paths) unless you add custom attributes to RESTRoute and make those available to the previous handlers... somehow.

I'm sure other applications are there but I don't see them. (licensing?)

If it is done in a way that "feels simple" both from a user perspective and from an "I want to create a new middleware without spending a week reverse engineering the code" perspective, this could be very useful.

expressjs architecturally makes the point, although the code, well, I mean...it's great Javascript. I'll just leave it at that. :)

(Middleware, that's another way of saying "handler list", isn't it? Why did we have to invent a new term for chains? Those crazy academics! It even has a next pointer, it's a linked list! :) )

So the idea would be that when a route matches (regular expression, remember?) instead of just invoking the route, you would pass the found RESTRoute to the first middleware, which then passes it to the second one, etc, with the final middleware typically being the current "invoke route" method. Attaching a chain of middlewares to the routes individually is going to be "interesting" because they match on regex's and you might have a lot of routes. Perhaps middlewares could be registered per-RESTResource?

It's doable. Without breaking backward compatibility. Efficiently. In a way that can be understood by humans. Sure why not?

[scottoffen]

I've been working in Node.js (and Express) almost exclusively for the past year since releasing Grapevine. I really like the patterns exposed by Express. In general, I like the idea, and I've even considered utilizing something like that for my Perl REST implementation.

Feasibility aside, my larger concern with this idea rests with the different use case/market niche Grapevine is designed to server verses Node/Express. I'm skeptical about breaking the principle of simplicity that is at the core of Grapevine.

To be clear, that's not a no. Certainly it is worth thinking about, and I'll put some thought into it.

[reppners]

expressjs architecturally makes the point, although the code, well, I mean...it's great Javascript. I'll just leave it at that. :)

Hehe, I know what you mean.

Attaching a chain of middlewares to the routes individually is going to be "interesting" because they match on regex's and you might have a lot of routes. Perhaps middlewares could be registered per-RESTResource?

I don't think there should be rules for limiting the registered middlewares (route handlers) to a single RESTResource. It should fall in place with the declared regex'es naturally. So the url should in some way give a handle by targeting a certain part of the url/regex which can be shared by a const-string variable that is reusable in attributes and thus the regex'es. But the presence of a priority on the attribute should be enforced so the order of middlewares is reliable.

Which leaves the user with maintaining the priority numbers - this I think could be a problem because maintaining this on dozens of routes might not be that funny - assuming they are global. So I get your point in giving the library user a way to maintain his middlewares in a way that is managable even with a large number of routes. It just should be easy without introducing new concepts at any level of "scope". But maybe introduce/use a single concept that works at any level (spanning mutliple RESTResources or just one).

Feasibility aside, my larger concern with this idea rests with the different use case/market niche Grapevine is designed to server verses Node/Express. I'm skeptical about breaking the principle of simplicity that is at the core of Grapevine.

I've always looked at Grapevine of being a pendant to Express (in terms of how to setup a server and write route handling logic for it, not the way it might scale). Am I wrong with my perspective on Grapevine?

When I was looking for a small REST-Server implementation I didn't find any alternative to Grapevine that had this simple and declarative approach to it. Maybe I didn't search hard enough or do not know enough places where to search for, but it was the simple and declarative approach of Grapevine that was promising and it did work out well so far (putting some minor flaws and bugs aside that are already fixed in some of the PR's).

Done right, I think the middleware concept can be brought to grapevine with all the benefits of giving people the chance to provide and use components for getting stuff done. For example I've written adapter code for parsing js-data querys to something that can be consumed with dynamic linq. Those pieces of logic might also be candidates for middleware. Because there would be a defined API of the ins and outs of a middleware component things like that could start to grow.

[scottoffen]

I've always looked at Grapevine of being a pendant to Express (in terms of how to setup a server and write route handling logic for it, not the way it might scale). Am I wrong with my perspective on Grapevine?

In that regard, I think your perspective is spot on.

In terms of the simplicity I'm referring to, I explicitly made the choice to have the server discover the routes, rather than requiring the consumer of the library to register them. (Although the argument could be made that the way the attributes work is akin to registering them.) I felt that the register-first approach would introduce complexity in both Grapevine and the users implementation.

That was then, this is now.

I think a register-first/discover-second hybrid approach could be implemented that would add the flexibility of chained middleware without detracting from the simplicity of the declarative approach.

Given the broad scope of the change, and my inability at this point to guarantee backwards compatibility, the implantation of this change would increment the major version number.

[reppners]

I think a register-first/discover-second hybrid approach could be implemented that would add the flexibility of chained middleware without detracting from the simplicity of the declarative approach.

Sounds like the right approach to have best of both worlds.

Given the broad scope of the change, and my inability at this point to guarantee backwards compatibility, the implantation of this change would increment the major version number.

When middleware can only be registered rather then discovered, than a breaking change can be avoided. Otherwise a deprecation notice could be added when discovered route handlers do not match the required middleware-signature.

So the question is: Should middleware only be registered on a server instance and not be discoverable?

To me it sounds like the right thing because using middlewares is something new and would not be mixed with the final route handlers. Also the order of middlewares would be defined naturally by the library user when he registers the different middlewares, so it happens rather in one place and is not separated in many files where an attribute is used to make the middleware discoverable.

[tekhedd]

For reference, I counted and my current project has exactly (!) 100 routes at the moment, not including static data handlers. This is pretty typical, I'd say, maybe a little above average.

(I tend to prefer explicitly registering things myself, but hey I'll go along with whatever works these days.)

[scottoffen]

Completed in dev for 4.0

[scottoffen]

@reppners and @tekhedd I've implemented this concept more fully in Grapevine 5 (https://github.com/scottoffen/grapevine). There are event handlers on IRestServer.OnRequest where middleware can be added (for things that might affect whether or not the request even gets routed) and on IRouter.BeforeRoutingAsync and IRouter.AfterRoutingAsync.