Ideas to discuss

[djzort]

With some time on my hands i thought i would throw up some ideas in the hope of having some good discussions.

How are protocol details (i.e. http, https, http2 etc) made available to the code? Or perhaps how should they be made available?

Use cases: Ensuring only https is used in some or all circumstances. Logging ciphers used, potentially linking them with customers so that removing ciphers impact is understood in terms of impacted customers (both I have encountered in the last 12-18 months)

Parameter & Data Normalization

Use cases: Times and Dates are the most common. Automatically converting ISO string dates from REST in to an object, and from the object in to the preferred format of a database. Then the other way. (This is one of my biggest wishes for Catalyst and friends)

Nonce Helpers

Use cases: For financial transactions especially a hidden nonce value is vital to ensuring an action only takes place one (ie when a use gets frustrated and hits "reload" they dont want their cc to be charged over again).

Authentication & Authorization

how could this be made more pluggable and cofigurable?

Accounting / Charge Back

ive never seen this in any foss framework, yet internal chargeback is fairly common in large organizations and hugely important for paid api services.

Rate Limiting / Throttling

Currently i have achieved this via middleware, but it could be more flexible

Paginating & Bulk Helpers

Health and Performance Monitoring (instrumentation)

This is a wide topic

Config File Helpers

There is a ticket open for this

DB Connection Pooling etc

Like Apache::DBI but could go as far as to have sugar like Dancer does

Logging enhancements

One idea that would be neat is something to help with providing formal error codes and error id's that can be linked to logged data. Also some help in ensuring data returned to clients is sanitized.

For clients this has always looked bespoke. It would be interesting to discuss how it could be provided in a general case solution in 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.