Added make-clack-middleware

[BnMcGn]

Using clack's :mount middleware to insert a snooze app in an existing
clack application doesn't work too well. Clack modifies the :path-info
field but snooze's make-clack-app reads from :request-uri. Fixing that
requires reassembling the URL from :path-info, :query-string, etc.

Adding make-clack-middleware is a simpler, cleaner solution.

[joaotavora]

This is interesting, I like that it's a full solution with support in the README.md, but I don't have a lot of time to analyse, and I have no idea what a "middleware" is. I'll just ask: why would someone need make-clack-app after this? Why not remove it, or at least deprecate it by "unmentioning" it in the README?

In another approach, wouldn't "reworking" make-clack-app work? Or is an "app" drastically different from a "middleware"?

[BnMcGn]

Heh. Good questions. Clack runs a stack of middleware with an app at the end. The big difference is that a middleware will pass on things to the next app-or-middleware on the stack when it can't deal with them, where an app won't. Apps are the end of the line. I think there's a case for both. You might serve up your whole app through snooze, or be running a standalone json server, etc. You would use make-clack-app for that. In my case I want to use snooze for some backend stuff, but have an existing clack "app" that will serve up the html frontend. So make-clack-middleware is more suitable. If you want to use middleware as the end app, you probably have to add a dummy cap app that returns 404s. I would say that it is simpler to provide both options to your end users. Apps aren't too drastically different from middleware. You'll see that make-clack-middleware is a fairly thin wrapper around make-clack-app. Even if you rework make-clack-app, I'd still have to wrap it in clack's :mount middleware. Mount feels a bit hacky. You end up doing something like (:mount "/rest" (snooze:make-clack-app)), then calling, eg.: /rest/item, but snooze will receive /item, being tricked into thinking that it is the main app instead of on a side branch. This will probably break your really nice defgenpath thing. Regards, Ben

…

On Tue, Jul 28, 2020 at 11:06 AM João Távora ***@***.***> wrote: This is interesting, I like that it's a full solution with support in the README.md, but I don't have a lot of time to analyse, and I have no idea what a "middleware" is. I'll just ask: why would someone need make-clack-app after this? Why not remove it, or at least deprecate it by "unmentioning" it in the README? In another approach, wouldn't "reworking" make-clack-app work? Or is an "app" drastically different from a "middleware"? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#23 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB4KLDUA4FT5WFHCQON4BBLR54HSHANCNFSM4PKYYVVA> .

[mdbergmann]

Apps aren't too drastically different from middleware.

I was also completely confused by the term "middleware" and how it's used.
"Middleware" in a layered software is a middle layer, or an adapter layer.
The usage in Clack kind of more like a decorator pattern.

[BnMcGn]

Decorator? Yeah that sounds about right. Clack is modelled after Ruby/Rack. It appears to borrow terminology from the same.

…

On Tue, Jul 28, 2020 at 12:03 PM Manfred Bergmann ***@***.***> wrote: Apps aren't too drastically different from middleware. I was also completely confused by the term "middleware" and how it's used. "Middleware" in a layered software is a middle layer, or an adapter layer. The usage in Clack kind of more like a decorator pattern. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#23 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB4KLDQVW2BLP73AQSXAXGDR54OHXANCNFSM4PKYYVVA> .