server-store mode for debug middlware

[Jonathan Swartz]

Plack::Middleware::Debug is fantastic and impressive to everyone I show it to. But it does have a few limitations:

* It doesn't work for requests that don't generate HTML (e.g. AJAX, dynamic images, form posts that redirect)

* The debug info gets sent for every page, adding a payload even if you never look at the information. This gets worse as your debug info gets more deep/complex.

I think the solution for both these problems is to store the content and debug information for each response on the *server side*, keyed by a unique id. You could then fetch it on demand, and you could present an interface to go back and look at response history. A cookie would tie together all of your previous requests so that the interface would know which ones to show you.

The data could be stored via any cache object, which would auto-purge old responses based on age or available space.

This would be a separate mode or subclass. The current debug mechanism is obviously simpler and still works well enough for many people's purposes.

Before I dive in, anyone doing/planning anything like this? Any advice on how to architect it or where to put it?

Thanks!
Jon

[Pedro Melo]

Hi,

I have something similar working here. Here are my thoughs based on
about 6 month experience with it.

I didn't use Middleware::Debug, instead I have a separate App that
ties to the storage backend. Why? because I can use the same app to
see the log of any request, either on devel, or in production (I can
tag a client with a "debug this client only").

Every request checks the "debug level" flag (than can be per user) and
this is used by the logging module (custom made in this case), and our
timing infrastructure (pretty name for a 10 line module that uses
Time::HiRes to time a anon sub and submit the result to the logger
module.)

Every request gets a UUID. This UUID is sent back to the app in a
cookie. We can enable a JS bit on any page (currently via console, I
need to tweak that into bookmarklet-fu), that adds a small debug box
that link to our backend where the debug App resides with the
appropriate UUID.

We can also track the last N Request<->UUID<->authenticated_user on
our back office.

On the debug app, I can see the logs, the timing information, and some
business stuff we extract from the logs.

What I think is worth sharing? The API the debug App uses. If it can
be done in a modular way like the current Middleware::Debug, you would
only need to standardize the API each panel would use to fetch the
information. This would allow anyone to either reuse the app with his
pluggable panel setup, or build a new debug app using the same API.

Either way, adding new panels (for ex, a better SQL logger) would mean:

* define the API;
* add sample panel to debug app.

I don't know if it would be helpful to tackle the collection and/or
storage of the information server-side. There is too many choices of
logging infrastructure, storage infrastructure, to build a single
solution to that part IMHO.

Just my €0.01.

Bye,
--
Pedro Melo
@pedromelo
http://www.simplicidade.org/
http://about.me/melo
xmpp:me...@simplicidade.org
mailto:me...@simplicidade.org

[Pedro Melo]

Hi,

forgot to clarify a single paragraph:

On Fri, May 25, 2012 at 10:07 AM, Pedro Melo <me...@simplicidade.org> wrote:
> Hi,

>
> I didn't use Middleware::Debug, instead I have a separate App that
> ties to the storage backend. Why? because I can use the same app to
> see the log of any request, either on devel, or in production (I can
> tag a client with a "debug this client only").

This is the key point for me: whatever you do, don't assume that it
will be the same browser/person/machine that does the request you want
to debug, and the one that gets the debug information.