Ideas to discuss about raisin

[khrt]

Are those points something which supposed to be resolved by a micro-framework like this?

Some points listed here are either solved by middleware or Moose compatible type with coercion,
and some seems to me like application logic problems, i.e. Accounting / Charge Back, Nonce Helpers & error codes.

What I find interesting to myself is an instrumentation for monitoring, like Prometheus or similar, but again, shouldn't this be solved by Plack/PSGI/middlewares?

[khrt]

What might also be useful is to start listing Raisin compatible middlewares/plugins if they're open-sourced and, but not necessary, are listed on CPAN.

[djzort]

I think pointing at some middlewares is a good idea for anything thats already our there. Such a list of links would help people using Raisin solve problems without reinventing the wheel.

In terms of instrumentation something in middleware would provide high level but ultimately be limited to whats passing through the middlware. For example Plack::Middleware::Statsd provides response times per uri but doesnt facilitate diving in more deeply (i.e timing for db queries). Dancer::Plugin::StatsD and Mojolicious::Plugin::Statsd are examples of how a more generic interface can be provided to record timings. However in both cases they are obviously Statsd rather than being a more generic pluggable interface that might facilitate other metric collection technologies.

[jonassmedegaard]

https://metacpan.org/pod/Metrics::Any seems a good generic monitoring library - implemented similar to Log::Any (which I also recommend using instead of custom default code) to be so lightweight that it gets virtually compiled away if unused.