Using Dancer2 as a website framework
Hi, I'm hoping for the community's input on whether Dancer is an appropriate framework for our project. We're building a website that wraps functionality exposed by an existing Perl EPP library. Perl has great EPP support and we don't want to re-implement that library in another language. In the medium term, the website will need to offer a fairly rich user experience that calls out to other databases and services beyond this one library. We're exploring two options: 1. use Dancer to build the entire website 2. use Dancer to power a thin REST API around the library and use another framework (eg. in Python) to build the rich website experience. Our requirements include: * move quickly, use the right tool for the job (ie. favour re-using components over building everything from scratch) * modern website tooling, such as SASS for CSS, good HTML form support, model validation * well documented and mature software * relatively easy for other devs to work on the project later I'm deliberately trying to avoid a language flame war. Rather, I'm evaluating based on the size and maturity of the User Experience/UI section of the Perl community. Dancer seems well placed for API servers, but the web dev communities seem to be focused around Ruby, Python, Node etc. which is making me lean toward option (2) above. Is that a reasonable evaluation? What do you all think? Thanks, Greg
On Fri, 23 Aug 2013 12:21:29 +0200 Greg Kempe <gregkempe@gmail.com> wrote:
I'm deliberately trying to avoid a language flame war. Rather, I'm evaluating based on the size and maturity of the User Experience/UI section of the Perl community. Dancer seems well placed for API servers, but the web dev communities seem to be focused around Ruby, Python, Node etc. which is making me lean toward option (2) above. Is that a reasonable evaluation?
Don't conflate front-end and back-end technologies. Dancer will make writing the back-end parts trivially easy; and make it easy to do the front-end however you like (simple and easy templating support, etc). Your choice of back-end framework needn't have much to do with how you develop the front end. -- David Precious ("bigpresh") <davidp@preshweb.co.uk> http://www.preshweb.co.uk/ www.preshweb.co.uk/twitter www.preshweb.co.uk/linkedin www.preshweb.co.uk/facebook www.preshweb.co.uk/cpan www.preshweb.co.uk/github
Hey Greg, I hope it's not too late to chime in. On Fri, Aug 23, 2013 at 1:21 PM, Greg Kempe <gregkempe@gmail.com> wrote:
[...] We're building a website that wraps functionality exposed by an existing Perl EPP library. Perl has great EPP support and we don't want to re-implement that library in another language. In the medium term, the website will need to offer a fairly rich user experience that calls out to other databases and services beyond this one library.
Sounds good.
We're exploring two options:
1. use Dancer to build the entire website 2. use Dancer to power a thin REST API around the library and use another framework (eg. in Python) to build the rich website experience.
Our requirements include:
* move quickly, use the right tool for the job (ie. favour re-using components over building everything from scratch) * modern website tooling, such as SASS for CSS, good HTML form support, model validation * well documented and mature software * relatively easy for other devs to work on the project later
I'm deliberately trying to avoid a language flame war. Rather, I'm evaluating based on the size and maturity of the User Experience/UI section of the Perl community. Dancer seems well placed for API servers, but the web dev communities seem to be focused around Ruby, Python, Node etc. which is making me lean toward option (2) above. Is that a reasonable evaluation?
The way I suggest people write their website is by separating the application logic from the web layer. I usually implement an API with routes defined under MyApp/Web.pm. The rest of MyApp/ contains all the application logic that can survive and live without the web layer, if needs be. In your case, writing just the web layer would be very simple. You could then transition it to your use application, written in whatever language you want. If you write it correctly, you could switch from Dancer to a different web framework (whether in Perl or not). Hope that helps, and good luck with your endeavor! :) Sawyer.
On 28. 8. 2013 18:56, sawyer x wrote:
Hey Greg,
I hope it's not too late to chime in.
On Fri, Aug 23, 2013 at 1:21 PM, Greg Kempe <gregkempe@gmail.com <mailto:gregkempe@gmail.com>> wrote:
[...] We're building a website that wraps functionality exposed by an existing Perl EPP library. Perl has great EPP support and we don't want to re-implement that library in another language. In the medium term, the website will need to offer a fairly rich user experience that calls out to other databases and services beyond this one library.
Sounds good.
We're exploring two options:
1. use Dancer to build the entire website 2. use Dancer to power a thin REST API around the library and use another framework (eg. in Python) to build the rich website experience.
Our requirements include:
* move quickly, use the right tool for the job (ie. favour re-using components over building everything from scratch) * modern website tooling, such as SASS for CSS, good HTML form support, model validation * well documented and mature software * relatively easy for other devs to work on the project later
I'm deliberately trying to avoid a language flame war. Rather, I'm evaluating based on the size and maturity of the User Experience/UI section of the Perl community. Dancer seems well placed for API servers, but the web dev communities seem to be focused around Ruby, Python, Node etc. which is making me lean toward option (2) above. Is that a reasonable evaluation?
The way I suggest people write their website is by separating the application logic from the web layer. I usually implement an API with routes defined under MyApp/Web.pm. The rest of MyApp/ contains all the application logic that can survive and live without the web layer, if needs be.
In your case, writing just the web layer would be very simple. You could then transition it to your use application, written in whatever language you want. If you write it correctly, you could switch from Dancer to a different web framework (whether in Perl or not).
Hi, I'm interested in how exactly you write this API in the web layer, do you happen to have an example of this approach? or know of a project that uses it? Thanks for any help Adam
On Thu, Aug 29, 2013 at 12:31 PM, Adam Witney <awitney@sgul.ac.uk> wrote:
On 28. 8. 2013 18:56, sawyer x wrote:
The way I suggest people write their website is by separating the application logic from the web layer. I usually implement an API with routes defined under MyApp/Web.pm. The rest of MyApp/ contains all the application logic that can survive and live without the web layer, if needs be.
In your case, writing just the web layer would be very simple. You could then transition it to your use application, written in whatever language you want. If you write it correctly, you could switch from Dancer to a different web framework (whether in Perl or not).
Hi,
I'm interested in how exactly you write this API in the web layer, do you happen to have an example of this approach? or know of a project that uses it?
I can't share any of the examples I have. They aren't open-source. However, it's really not at all complicated. Imagine having MyApp.pm that has: use Moose; # or Moo has ... has ... sub do_something {...} and then you have MyApp/Web.pm that has: use Dancer2; my $app = MyApp->new; # define routes here get '/' => sub { $app->do_something(...) }; ----- That way you separate the application logic from the web logic.
I usually do the opposite in MyApp I have the Dancer stuff, in MyApp:: something I have the logical I also separate the access to the data in another module So I can test separately each part of my app 2013/9/3 sawyer x <xsawyerx@gmail.com>
On Thu, Aug 29, 2013 at 12:31 PM, Adam Witney <awitney@sgul.ac.uk> wrote:
On 28. 8. 2013 18:56, sawyer x wrote:
The way I suggest people write their website is by separating the application logic from the web layer. I usually implement an API with routes defined under MyApp/Web.pm. The rest of MyApp/ contains all the application logic that can survive and live without the web layer, if needs be.
In your case, writing just the web layer would be very simple. You could then transition it to your use application, written in whatever language you want. If you write it correctly, you could switch from Dancer to a different web framework (whether in Perl or not).
Hi,
I'm interested in how exactly you write this API in the web layer, do you happen to have an example of this approach? or know of a project that uses it?
I can't share any of the examples I have. They aren't open-source. However, it's really not at all complicated.
Imagine having MyApp.pm that has: use Moose; # or Moo has ... has ...
sub do_something {...}
and then you have MyApp/Web.pm that has: use Dancer2; my $app = MyApp->new;
# define routes here get '/' => sub { $app->do_something(...) };
-----
That way you separate the application logic from the web logic.
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
On Wed, Sep 4, 2013 at 9:14 AM, Celogeek San <me@celogeek.com> wrote:
I usually do the opposite
in MyApp I have the Dancer stuff, in MyApp:: something I have the logical I also separate the access to the data in another module
So I can test separately each part of my app
I don't think you followed me completely. I can fully test separately each part of my app. The web logic is under ::Web, the rest is under MyApp or ::API. They are cleanly separated and can be easily tested.
On Fri, Aug 23, 2013 at 1:21 PM, Greg Kempe <gregkempe@gmail.com> wrote:
..
We're exploring two options:
1. use Dancer to build the entire website 2. use Dancer to power a thin REST API around the library and use another framework (eg. in Python) to build the rich website experience.
Our requirements include:
* move quickly, use the right tool for the job (ie. favour re-using components over building everything from scratch) * modern website tooling, such as SASS for CSS, good HTML form support, model validation * well documented and mature software * relatively easy for other devs to work on the project later
Look at http://earth-base.org It is a Dancer1 app on server side (but it would be the same were it Dancer2) sitting between the client and various data stores (Postgres, raster files, text files, etc.). The client can be a browser (which is what you will see if you try out any of the http://earth-base.org/apps) in which case all the work is done by OpenLayers or Leaflet, jQuery, D3, etc. The client could also be other programs such as R, Python, anything that can query the server over http. As far as the clients are concerned, they have no idea what the backend is written in, and what the data stores are. Hope this gives you a few ideas. -- Puneet Kishor http://punkish.org science http://earth-base.org advocacy http://creativecommons.org
Hi Greg, On Fri, Aug 23, 2013, at 08:21 PM, Greg Kempe wrote:
We're exploring two options:
1. use Dancer to build the entire website 2. use Dancer to power a thin REST API around the library and use another framework (eg. in Python) to build the rich website experience.
Why not both? I would suggest something like nginx as a frontend which passes the request up to your Dancer API, Python CGI, Ruby CGI, static HTML files (generated from Perl, Python etc) etc. That way, it doesn't matter what you write your front/backend in. It's configurable all the way down. Alfie -- Alfie John alfiej@opera.com
Hi Alfie, We're essentially going this route by choosing option 2 so that we can use the right tool for the job (Perl in one case, Python in another) and hosting them together. Thanks for the thoughts, good to have some agreement. Greg On 28 August 2013 at 10:58:42 PM, Alfie John (alfiej@opera.com) wrote: Hi Greg, On Fri, Aug 23, 2013, at 08:21 PM, Greg Kempe wrote:
We're exploring two options:
1. use Dancer to build the entire website 2. use Dancer to power a thin REST API around the library and use another framework (eg. in Python) to build the rich website experience.
Why not both? I would suggest something like nginx as a frontend which passes the request up to your Dancer API, Python CGI, Ruby CGI, static HTML files (generated from Perl, Python etc) etc. That way, it doesn't matter what you write your front/backend in. It's configurable all the way down. Alfie -- Alfie John alfiej@opera.com
On 23/08/2013 11:21, Greg Kempe wrote:
We're exploring two options:
1. use Dancer to build the entire website 2. use Dancer to power a thin REST API around the library and use another framework (eg. in Python) to build the rich website experience.
I don't quite understand how Python or Ruby is any better suited to creating a "rich website experience" than Perl. Front end is HTML, CSS and Javascript if you're using a REST API so using more than one server-side languaged doesn't make much sense to me. gvim
I initially felt the same way when I read that, because I'm a Perl guy, and I see Perl as being suitable for pretty much anything you want to do. I assume that in considering "suitability," Greg is considering things like "how many of us are comfortable building and maintaining a website in a certain language." The truth is that there's nothing unsuitable about any of the languages he mentioned for the task. What he's really doing is using Perl for the part of the project that he wants to use Perl for, and Python for the part that he wants to use Python for. Fortunately, Dancer is a really nice way to abstract away stuff that is most easily done in Perl, so it can be consumed by other languages doing other things. Although I would certainly tell him that you can build the whole thing in Perl -- because you certainly can, I was also going to tell him that making a Dancer web service would be perfectly good solution as well. On Mon, Sep 2, 2013 at 6:41 PM, gvim <gvimrc@gmail.com> wrote:
On 23/08/2013 11:21, Greg Kempe wrote:
We're exploring two options:
1. use Dancer to build the entire website 2. use Dancer to power a thin REST API around the library and use another framework (eg. in Python) to build the rich website experience.
I don't quite understand how Python or Ruby is any better suited to creating a "rich website experience" than Perl. Front end is HTML, CSS and Javascript if you're using a REST API so using more than one server-side languaged doesn't make much sense to me.
gvim
______________________________**_________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/**mailman/listinfo/dancer-users<http://lists.preshweb.co.uk/mailman/listinfo/dancer-users>
Use other language for the frontend may have some advantage. The first I see, is that you can have more developer available in other language to maintain the frontend. It's easier to find PHP Zend developer than Perl Web developer. Also true for python. 2013/9/3 gvim <gvimrc@gmail.com>
On 23/08/2013 11:21, Greg Kempe wrote:
We're exploring two options:
1. use Dancer to build the entire website 2. use Dancer to power a thin REST API around the library and use another framework (eg. in Python) to build the rich website experience.
I don't quite understand how Python or Ruby is any better suited to creating a "rich website experience" than Perl. Front end is HTML, CSS and Javascript if you're using a REST API so using more than one server-side languaged doesn't make much sense to me.
gvim ______________________________**_________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/**mailman/listinfo/dancer-users<http://lists.preshweb.co.uk/mailman/listinfo/dancer-users>
On Tue, Sep 3, 2013 at 5:44 PM, Celogeek San <me@celogeek.com> wrote:
Use other language for the frontend may have some advantage. The first I see, is that you can have more developer available in other language to maintain the frontend.
It's easier to find PHP Zend developer than Perl Web developer. Also true for python.
There is a major problem with that approach. The reason it's easier to find a PHP developer is because the language is cheap. It's really easy to learn, and tons of people learn it to get a job. The PHP knowledge pool is very shallow though. That means almost PHP developers are very shitty developers that stopped learning because PHP doesn't really have a very proficient level to it. So companies that figure "hey, there are more PHP developers than Perl/Python/Ruby - I'll get programmers in those!" end up with really really horribly shitty code that it's impossible for them to actually get beyond of. I've worked at a lot of these companies. It's horrible. Really horrible. Don't be duped by number of developers overall. Think about "available developers", "developer knowledge and expertise" and "ability to provide a good product". Who gives a shit if there are less developers if I can still find enough?
Of course. But at least you can find some. It is not obvious to find a good web perl developer. I can see that in my company. Le 7 sept. 2013 23:24, "sawyer x" <xsawyerx@gmail.com> a écrit :
On Tue, Sep 3, 2013 at 5:44 PM, Celogeek San <me@celogeek.com> wrote:
Use other language for the frontend may have some advantage. The first I see, is that you can have more developer available in other language to maintain the frontend.
It's easier to find PHP Zend developer than Perl Web developer. Also true for python.
There is a major problem with that approach. The reason it's easier to find a PHP developer is because the language is cheap. It's really easy to learn, and tons of people learn it to get a job. The PHP knowledge pool is very shallow though. That means almost PHP developers are very shitty developers that stopped learning because PHP doesn't really have a very proficient level to it.
So companies that figure "hey, there are more PHP developers than Perl/Python/Ruby - I'll get programmers in those!" end up with really really horribly shitty code that it's impossible for them to actually get beyond of. I've worked at a lot of these companies. It's horrible. Really horrible.
Don't be duped by number of developers overall. Think about "available developers", "developer knowledge and expertise" and "ability to provide a good product". Who gives a shit if there are less developers if I can still find enough?
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
I've seen a company with 2 web developers in Ruby doing a hell of a lot more than 40 developers in PHP in another team. "Finding one" isn't in and of itself a quality or something to consider. You're probably better off having someone who knows programming (Ruby/Perl/Python) move to web, rather than getting a PHP programmer. On Sun, Sep 8, 2013 at 1:17 AM, Celogeek San <me@celogeek.com> wrote:
Of course. But at least you can find some. It is not obvious to find a good web perl developer. I can see that in my company. Le 7 sept. 2013 23:24, "sawyer x" <xsawyerx@gmail.com> a écrit :
On Tue, Sep 3, 2013 at 5:44 PM, Celogeek San <me@celogeek.com> wrote:
Use other language for the frontend may have some advantage. The first I see, is that you can have more developer available in other language to maintain the frontend.
It's easier to find PHP Zend developer than Perl Web developer. Also true for python.
There is a major problem with that approach. The reason it's easier to find a PHP developer is because the language is cheap. It's really easy to learn, and tons of people learn it to get a job. The PHP knowledge pool is very shallow though. That means almost PHP developers are very shitty developers that stopped learning because PHP doesn't really have a very proficient level to it.
So companies that figure "hey, there are more PHP developers than Perl/Python/Ruby - I'll get programmers in those!" end up with really really horribly shitty code that it's impossible for them to actually get beyond of. I've worked at a lot of these companies. It's horrible. Really horrible.
Don't be duped by number of developers overall. Think about "available developers", "developer knowledge and expertise" and "ability to provide a good product". Who gives a shit if there are less developers if I can still find enough?
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
Well, I don't love php anymore, even if i have start with it, and do i hope good job on builder home made extranet, We use php for our frontend, and it is a company decision, so now we got big product, it is hard to switch. But I love building web site with Perl, and it is hard to apply it to a company. at least in my case. 2013/9/8 sawyer x <xsawyerx@gmail.com>
I've seen a company with 2 web developers in Ruby doing a hell of a lot more than 40 developers in PHP in another team.
"Finding one" isn't in and of itself a quality or something to consider. You're probably better off having someone who knows programming (Ruby/Perl/Python) move to web, rather than getting a PHP programmer.
On Sun, Sep 8, 2013 at 1:17 AM, Celogeek San <me@celogeek.com> wrote:
Of course. But at least you can find some. It is not obvious to find a good web perl developer. I can see that in my company. Le 7 sept. 2013 23:24, "sawyer x" <xsawyerx@gmail.com> a écrit :
On Tue, Sep 3, 2013 at 5:44 PM, Celogeek San <me@celogeek.com> wrote:
Use other language for the frontend may have some advantage. The first I see, is that you can have more developer available in other language to maintain the frontend.
It's easier to find PHP Zend developer than Perl Web developer. Also true for python.
There is a major problem with that approach. The reason it's easier to find a PHP developer is because the language is cheap. It's really easy to learn, and tons of people learn it to get a job. The PHP knowledge pool is very shallow though. That means almost PHP developers are very shitty developers that stopped learning because PHP doesn't really have a very proficient level to it.
So companies that figure "hey, there are more PHP developers than Perl/Python/Ruby - I'll get programmers in those!" end up with really really horribly shitty code that it's impossible for them to actually get beyond of. I've worked at a lot of these companies. It's horrible. Really horrible.
Don't be duped by number of developers overall. Think about "available developers", "developer knowledge and expertise" and "ability to provide a good product". Who gives a shit if there are less developers if I can still find enough?
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
I've seen (and worked at) many companies that have PHP for the frontend. They usually end up stuck with disgusting code that is very difficult to play with since the language is deficient (that's me avoiding uses curses) and the developers are usually not the best (which is what PHP usually offers). As you put it, it's hard to switch. That's true. That's why I'm saying you shouldn't go with the gut feeling of "there's a lot of PHP devs out there, then working with it means I'll always be able to hire", because that leads you to "omg we're stuck with shitty PHP and shitty developers and now it's too hard to switch". Seen it too many times. That's similar to people saying you can't find Perl developers. That's not true. Perl developers exist, and they simply have no trouble finding a job (a *good* job) and so they're less visible on the market. They usually already have a job. :) Gut feelings are not always true. On Sun, Sep 8, 2013 at 1:37 AM, Celogeek San <me@celogeek.com> wrote:
Well, I don't love php anymore, even if i have start with it, and do i hope good job on builder home made extranet,
We use php for our frontend, and it is a company decision, so now we got big product, it is hard to switch.
But I love building web site with Perl, and it is hard to apply it to a company. at least in my case.
2013/9/8 sawyer x <xsawyerx@gmail.com>
I've seen a company with 2 web developers in Ruby doing a hell of a lot more than 40 developers in PHP in another team.
"Finding one" isn't in and of itself a quality or something to consider. You're probably better off having someone who knows programming (Ruby/Perl/Python) move to web, rather than getting a PHP programmer.
On Sun, Sep 8, 2013 at 1:17 AM, Celogeek San <me@celogeek.com> wrote:
Of course. But at least you can find some. It is not obvious to find a good web perl developer. I can see that in my company. Le 7 sept. 2013 23:24, "sawyer x" <xsawyerx@gmail.com> a écrit :
On Tue, Sep 3, 2013 at 5:44 PM, Celogeek San <me@celogeek.com> wrote:
Use other language for the frontend may have some advantage. The first I see, is that you can have more developer available in other language to maintain the frontend.
It's easier to find PHP Zend developer than Perl Web developer. Also true for python.
There is a major problem with that approach. The reason it's easier to find a PHP developer is because the language is cheap. It's really easy to learn, and tons of people learn it to get a job. The PHP knowledge pool is very shallow though. That means almost PHP developers are very shitty developers that stopped learning because PHP doesn't really have a very proficient level to it.
So companies that figure "hey, there are more PHP developers than Perl/Python/Ruby - I'll get programmers in those!" end up with really really horribly shitty code that it's impossible for them to actually get beyond of. I've worked at a lot of these companies. It's horrible. Really horrible.
Don't be duped by number of developers overall. Think about "available developers", "developer knowledge and expertise" and "ability to provide a good product". Who gives a shit if there are less developers if I can still find enough?
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
participants (9)
-
Adam Witney -
Alfie John -
Celogeek San -
David Precious -
Greg Kempe -
gvim -
John Ingram -
Mr. Puneet Kishor -
sawyer x