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 notifications@github.com 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 https://github.com/joaotavora/snooze/pull/23#issuecomment-665191615, 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 notifications@github.com 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 https://github.com/joaotavora/snooze/pull/23#issuecomment-665220751, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB4KLDQVW2BLP73AQSXAXGDR54OHXANCNFSM4PKYYVVA .