Turn Koha into a Mojolicious application
Julian Maurice
Public
Seen by 41
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20582
Pros:
- Builtin webserver
- No need for Apache2/Nginx in development
- Simpler Apache2/Nginx configuration in production
- Testable CGI scripts with Test::Mojo
- Starman and Plack middlewares can still be used
- URL rewriting and static files serving in the app means easier upgrades (no external configuration file to update - see Bug 12904)
- All Mojolicious features (routing, commands, plugins, ...)
- No new Perl dependencies
Cons:
- Koha will be tied to a specific framework
- It's a fast moving framework so there's an overhead to that with regards to maintaining the debian dependency and also keeping the code up to date with the latest developments in the framework
Please add your pros and cons in comment.
Poll Created Mon 16 Apr 2018 12:39PM
Turn Koha into a Mojolicious application Closed Wed 16 May 2018 12:00PM
Results
| Results | Option | % of points | Voters | |
|---|---|---|---|---|
|
|
Agree | 0.0% | 0 | |
| Abstain | 0.0% | 0 | ||
| Disagree | 0.0% | 0 | ||
| Block | 0.0% | 0 | ||
| Undecided | 0% | 1 |
|
8 of 9 people have participated (88%)
clrh
Mon 14 May 2018 1:41PM
I do not develop enough to take position but I like the pros listed.
Julian Maurice Tue 17 Apr 2018 7:27AM
However, as my boss has pointed out, what happens when Mojolicious is replaced with another framework? After all, the author of the Mojolicious framework is the original author of the Catalyst framework. By switching to a framework, we will experience a certain amount of "lock in".
Mojolicious is here for more than 8 years and is still developed so I think it will not be replaced any time soon. And I prefer to be "locked in" Mojolicious than in CGI scripts :-)
Anyway, we already depends on Mojolicious for the rest api. So at least we can try to make the best of it.
David Cook Wed 18 Apr 2018 1:14AM
Catalyst has been around for 12 years and is still being developed. You never know when a new framework might rise up and be more popular.
Oh yeah I think CGI scripts are a dead end for a lot of what we need, but we could still write our own Plack compliant handlers. That said, using a framework will save us a tonne of time and energy and save us from making unnecessary errors.
Tomás Cohen Arazi Wed 18 Apr 2018 1:42AM
We are evolving in a good way. We've been and are moving business logic into testable modules and classes, and controller scripts are becoming thinner and less relevant.
We picked Mojolicious and there's no obvious reason to abandon it for now. And yes, a new routing system hooked into Plack could do part of its job. But no one is going to do it, right? It would mean writing our own framework which doesn't sound right. If we had the human hours to do that, we'd better complete our REST api or finish the Elasticsearch integration, right?
El mar., 17 abr. 2018 a las 22:14, David Cook (Framavox) (notifications@framavox.org) escribió:
David Cook Wed 18 Apr 2018 1:47AM
Oh I totally agree. I figured I'd just play devil's advocate to point out some of the cons.
David Cook Thu 19 Apr 2018 11:44PM
I've checked out the bug report in Bugzilla and this is actually really cool.
David Cook Thu 19 Apr 2018 11:47PM
I do wonder if this would be the death knell for Koha as a multitenant system?
Julian Maurice Fri 20 Apr 2018 7:28AM
I do wonder if this would be the death knell for Koha as a multitenant system?
I'm not sure of what is needed to have a multitenant Koha, but how is this worse than a plack setup ?
David Cook · Tue 17 Apr 2018 5:43AM
Overall, I like the idea of Koha becoming a MVC app with routing and everything you'd expect from a modern web application. I think it would make development and maintenance much nicer.
However, as my boss has pointed out, what happens when Mojolicious is replaced with another framework? After all, the author of the Mojolicious framework is the original author of the Catalyst framework. By switching to a framework, we will experience a certain amount of "lock in".
That said, if we can make Koha more modular, it might be easier to migrate frameworks in the future if necessary.
Mojolicious will also become a vital dependency that needs to be monitored and updated carefully. It's not like HTTP::OAI where we can just peg it to the old version of the code since it's not a vital part of the system. Any change to Mojolicious would ripple throughout the entire codebase.
But again... if we're able to make our controllers more modular, it could make testing and maintenance that much easier and then it might not be a problem.