Raisin
Raisin copied to clipboard
Ideas to discuss
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.
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?
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.
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.
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.