The foundation for your business
Fork me on GitHub
Re: [ledgersmb-devel] Dancer2 vs Plack::Request+Router::XS+Middlewares+TemplateToolkit+Beam::Wire ?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ledgersmb-devel] Dancer2 vs Plack::Request+Router::XS+Middlewares+TemplateToolkit+Beam::Wire ?

On 7/27/19 7:13 PM, Erik Huelsmann wrote:
> Hi,
> Last year, I started experimenting with Dancer2 (one of the options on the table for our target framework when we
> rewrite much of our code).
> Today, I've been updating that code to the HEAD of the current master branch. During the work I've done so far (last
> year and today), I've come across several obstacles which now lead me to bring up the following for discussion.
> So, let me start by stating which problem I think we're looking to solve: we need a means to do request parameter
> handling, session management, pluggable authentication, routing, management, template handling and abstraction of a
> templating library.
> During my experiments with Dancer2, I found that indeed it provides a framework with the desired properties. However, as
> with other frameworks, Dancer2 imposes its "framework structure" on applications. Normally this helps simplify the task
> of application development. Yet with the peculiarities in our code base, I'm finding that to implement required
> functionalities, I'm already working against the framework rather than with it:
>  1. Session management (cookies)
>      As part of the move from our current design to the Dancer2 framework, I'm aiming for setup.pl <http://setup.pl> and
> login.pl <http://login.pl> to become completely separate applications, meaning that they require separate authentication
> cookies (to allow separate, concurrent logins into both apps from a single browser)
>      While Dancer2 does support multiple apps running on a single instance of its framework (such as required to run
> login.pl <http://login.pl> and setup.pl <http://setup.pl> from the same backend), it doesn't support - in its
> configuration file (config.yml) - that these apps use disjoint session management cookies. In order to support this
> use-case, I've had to add request hooks, changing the name of the session cookie on a per-request basis.

Each of these apps should be able to have their own configuration directory so you can change the 'session_name'.
Alternatively you could change it directly in the script (setup.pl / login.pl).

>  2.Pluggable authentication
>     As LedgerSMB uses a rather unusual authentication scheme where the user+password+database name are required for
> login, our authentication scheme doesn't fit the standard set by the framework (Dancer2::Plugin::Auth::Extensible::*),
> I've ended up hacking "deep" into the internals of auth::extensible: our authentication couldn't be achieved without
> replacing the login templates and finding ways to make more parameters available than supported out of the box.

Where do you handle the authentication within LedgerSMB - I would like to take a look at it.

>  3. Templating library abstraction
>      While abstraction from templating libraries sounds nice, in practice it's cumbersome to switch templating
> libraries: on the Perl side the abstraction works fine to swap from one to another, but templating libraries usually use
> different templating "languages" (i.e. TemplateToolkit uses different directives and paradigms than XSLate). So, it
> seems that managing instantiation of the templating library is more important than abstracting it.

I would like to have a generic template abstraction and instantation outside of Dancer2, e.g. for sending automated

>  4. Route definition & dispatch
>      With the ability to define routes, we'll be able to detach URL structure from our internal code structure. Dancer2
> has a nice DSL to support the definition of routes for non-webservice entry points. There are plugins available to
> extend the DSL with convenience keywords for definition of webservice entry points.
>      However, the syntactic sugar provided by the endorsed plugin (Dancer2::Plugin::REST) provides 1 new DSL keyword
> which is nothing more than a way to attach 4 functions to a resource (create, get, update, delete) providing a generated
> route for each; I see very little benefit to this plugin. In addition, this plugin doesn't support HTTP's content
> negotiation; instead, it expects the requested resource to have an "extension" to indicate the desired response encoding
> (e.g.: /users/1.json returns JSON, /users/1.xml returns XML, etc). This isn't "http-native" enough for me and thereby
> unacceptable for our use. Then there's the (not endorsed) Dancer2::Plugin::WebService; however, this too encodes the
> desired response encoding in the URL...

I wouldn't say that that plugin is endorsed, it is rather a way to get a REST app working quickly. You could write a
custom plugin based on a description file which creates the routes on startup (see

It should be also possible to set a variable for the response encoding and use it at the end of the processing.


>  5. Framework configuration
>      Dancer2 supports running multiple "apps" on a single instance. We want to run multiple apps: our setup.pl
> <http://setup.pl> and login.pl <http://login.pl>. Even: we want these multiple apps to run on different authentication
> domains (i.e. when a user is logged in in /login.pl <http://login.pl>, we don't automatically want the user to be logged
> in into /setup.pl <http://setup.pl> too). During my experiments I found that this isn't something that Dancer2 supports
> in its configuration: it can be "tricked" to support it by installing the correct pre- and post-request hooks in the
> framework, but out-of-the-box, it's not there. I'm not sure what other areas this will affect in the future, but from
> the structure of the configuration, I'm imagining it'll be an issue in many places.
> So what is our way forward then? Well, while we were working to merge the Multi Currency branch and stabilizing the 1.7
> release (this process is still on-going), I've been looking around for solutions to these issues and I think the Perl
> library ecosystem has very nice options for almost all of the problems mentioned above, with the remark that there will
> obviously not be such a nice DSL as there will be with Dancer2. The following alternatives are available:
> 1. For session management using encrypted cookies, there's Session::Storage::Secure which works and is agnostic of
> underlying technology
> 2. For pluggable authentication, as we need to write our own authenticator anyway (and we actually already *have* that
> as a Plack middleware), I there's no effort if we can reuse that
> 3. For templating engine abstraction, well, I guess that with my line of reasoning above, there's little reason to have
> abstraction for templating engines at all (I mean, there *is* for a framework which needs to support many code bases,
> but there isn't for our specific use-case: our code base)
> 4. Route definition and dispatch (including extraction of route parameters) is available in a technology agnostic
> library Router::XS; while this library doesn't have the solid DSL that Dancer2 has, I'm expecting us to move more and
> more to Webservice entrypoints (either JSONRPC, GraphQL or REST) meaning that the DSL Dancer2 provides will be far less
> useful as stated above
> 5. Framework configuration could be handled through one of the regular YAML libraries, but even better - especially with
> inversion of control / dependency injection - we could turn to Beam::Wire and be able to deal with the most complex
> configurations by deferring configuration handling to sysadmins
> Obviously, Dancer2 will be able to do request parameter handling. That's something that's supported today too: we
> already have Plack::Request to handle parameter parsing (both URL and body parameters).
> So, after this long story, I'm wondering if moving to Dancer2 is worth it, or that we can simply stay on Plack with its
> middlewares and put the aforementioned modules to good use. Lets have your opinions and a good discussion on the matter
> so we lay a strong foundation for next steps for our project.
> Regards,
> -- 
> Bye,
> Erik.
> http://efficito.com <http://efficito.com/> -- Hosted accounting and ERP.
> Robust and Flexible. No vendor lock-in.
> _______________________________________________
> devel mailing list
> ..hidden..
> https://lists.ledgersmb.org/mailman/listinfo/devel

Ecommerce and Linux consulting + Perl and web application programming.
Debian and Sympa administration. Provisioning with Ansible.

Attachment: signature.asc
Description: OpenPGP digital signature

devel mailing list