Fwd: Plugins Request for Comment

[Josep Blanquer]

Cross posting from praxis-developers since this is as relevant to "users" of the framework as "developers" of Praxis itself.

I'm hoping to get some more feedback and/or validation that what we're building on the Plugin side satisfies everybody, and to know what other things we might be missing. Also it would be nice to see who wants to take this new feature and contribute to Praxis by implementing a useful plugin on their own! :)

Cheers,

Josep M.

---------- Forwarded message ----------
From: Josep Blanquer <blan...@rightscale.com>
Date: Fri, Nov 21, 2014 at 9:35 AM
Subject: Re: Plugins Request for Comment
To: Dane Jensen <da...@rightscale.com>
Cc: praxis-de...@googlegroups.com

I'm just going to give a little nudge to the list on this topic and I was hoping we can get some discussion or agreement on the features of our new underlying plugin system before we start committing code to master...after which point we can all can start building actual useful plugins on top.

So, from the framework perspective, does anybody see any missing "hook"? In other words, if you think of one or more plugin ideas you'd like to have built on top, can you think of what types of "things" the plugin would need to hook onto? and see if we have them all covered in the proposal?

I'm going to give a particular example to illustrate.

Imagine an Authentication plugin....it would conceptually need to hook into Praxis to:

- read and integrate a configuration file/data for the pluging config

- add "middleware/around filters" to inspect and/or gather data from headers, and place some result on the request object

- enhance the Praxis resource definition DSL so that the app can now say things like:  `requires_auth true` for the resources/actions that need it

- hook into the before filters of controllers to check if they "require_auth: true" or not ... and if they do, act accordingly (perhaps use the data stored in the request object by the middleware code)

- enhance the JSON doc generation of resource definitions to express the fact that some actions might require_auth (i.e. new JSON attributes generated in the docs)

- enhance the doc browser inputs so that it can actually render the auth requirements appropriately...maybe providing Angular templates that can be used when rendering the controllers... (*this is the only plugin feature is not designed/implemented yet in the current Plugin framework)

what else? what are we missing?

Similar things are true with an Authorization plugin, for example, where you'd need to end up enhancing the resource definition DSL to say things like "requires_roles :one, :two" ... with the corresponding, before filters, JSON doc and browser enhancements...

Similar for Logging-type plugins too....i.e. like Rails' "Processing X" heading line and a final "Completed X in (Yms) lines...

How about deeper things like "rewrelic"? would such a plugin need other types of hooks that we currently don't have to report nicely formatted data?

Another interesting discussion could be about Plugin dependencies...For example, the Authorization plugin would depend on an Authentication plugin...would that be good to be expressed? or is that something that the app builder would have to know and fix if that's not fulfilled?...

Anyway, I'd love to kickstart some of this discussions with anybody that thinks that Praxis' extensibility is as important as some of us think it is. 

This is the moment for you to describe your wish-list to make sure it covers your future "extensibility" needs! :)

Cheers,

Josep M.

On Tue, Nov 18, 2014 at 1:47 PM, Dane Jensen <da...@rightscale.com> wrote:

Pluggability is an important tenet for Praxis. For this reason there are many different extensibility points that can be used:

• before/after bootstrap stages (env, lib, app, etc.)

• before/after/around request stages (load, validate....)

• error handler (new)

• middleware (new)

• custom request class (partially-implemented)

• new data types (through Attributor types), including custom doc generation

• new JS templates to render custom types for the standard doc browser

• configuration loading, validating, coercing and singleton storage

But in addition, we want to:

• extend that pluggability into the of the design API.

• plus package all of the typical pieces into a plugin "abstraction" so that making use of all these functions by third parties can be streamlined as much as possible, rather than having to manage many different hooks individually.

To that effect, we have developed a base plugin concept that can be easily extended to greatly enhance a Praxis app, in a controlled yet deep-code manner. The idea behind this Plugin "packaging" is to start bringing typical "plugins" into Praxis that many apps can easily start using and providing their right configuration (if necessary).

Examples of such plugins can be: Database adapters, ORMs, authentication modules, authorization modules, common loggers, you name it...

In particular, plugins can easily extend the hook points by:

• Injecting custom DSL to resource and action definitions. i.e., for an authorization plugin you may want a "required_roles x, y, z..." syntax in your resource or action definitions. As a corollary, these plugins can also:

• generate/enhance the corresponding custom API docs to reflect their additions. i.e., a new section in the JSON doc for the resource definition that describes the roles. Plus (in the near future)

• even provide custom JS template snippets for the standard doc browser to show such things in the web-page when reviewing docs.

• Inject custom methods to the request object, as a generic and thread-safe way to pass information throughout the request lifecycle. i.e., the authentication plugin might set the current_user value early in the request lifecycle, so that other plugins can use it later on.

• Add before/after/around hooks to any or all of the existing controllers of the app, to perform whatever necessary actions. i.e., lookup and verify a user from a signed session, and set it to the "current_user" method of the request.

Currently planned plugins include:

• authentication

• authorization

• ORM support, specifically sequel and praxis-mapper

• statistics/notifications for both high-level metrics and fine-grained request details.

• better logging

There’s preliminary versions of the documentation for the error handler, middleware support, and plugins in a up in a gist (https://gist.github.com/careo/e744484bdd0ba165b015) while the plugins are in progress.

I’d appreciate any suggestions, feedback, or whatever you want to throw at me. Specifically on any key use cases we’re totally missing, or something you think we’re doing that’s totally stupid.

-Dane

--
You received this message because you are subscribed to the Google Groups "praxis-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to praxis-developm...@googlegroups.com.
To post to this group, send email to praxis-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/praxis-development/CA%2B77RR8y795NR0YfBgrc89-rZ8oNWamtq-3_ASFzVTOswJ6ECA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.