I've just started tinkering with Mojolicious, after spending some time playing with a variety of other frameworks in other languages (I'm starting a new web project, and wanted to make an informed decision about how to build it). Mojolicious gets so many things right in such a tiny package, I'm surprised more folks aren't using it or talking about it.
The real-time support is awesome; setting up Websockets is stupidly simple; coding non-blocking services is, I think, easier (at least more concise) than in Node.js (though it uses a similar callback model); testing is just perfect (Mojo has a user agent and DOM support, so you can write super concise tests for web services); building multiple outputs (like HTML for humans and JSON for API) for the same routes is excellent. So far, none of the frameworks I've looked at has been as concise or as...neat, I think might be the right word. So many things about it have me saying, "Now, why didn't someone think of that earlier?"
It's pretty tightly focused on just doing a few things really well, so it's not like a Rails, or even Django, experience...you have to make your own decisions about what ORM to use (or not to use an ORM), front end (though because it is agnostic about front end, you can use whatever you like pretty readily...so, React/Redux, Angular, whatever), and even nitty gritty stuff like authentication and accounts and such. I occasionally find myself wishing it had a little more batteries included, but mostly I like that it doesn't take days of doc/code spelunking to grasp the whole system.
Anyway, I'm not a Perl fanatic, though I like the language OK; especially in recent versions. So many little warts have gone away in recent years. But, the web service ecosystem in Perl is surprisingly strong and modern, given how unpopular it seems to have been in recent years. It's been a while since I really dug into what goes into building a new Perl system, and a lot of cool stuff has been completely off my radar. Mojolicious, in particular, is one of those things.
I occasionally find myself wishing it had a little more batteries included
Well, there's a lot of helper modules[1] on CPAN (somewhat different than the ones linked in the article), so that may alleviate that concern a little bit.
Mojolicious is bar-non one of my favorite Perl technologies. :)
Yeah, some of the modules are great. But, I mentioned my current paint point, which is user accounts. There's a couple of half solutions on CPAN, but nothing comparable to accounts support available in Rails or Django, or almost any of the other "big" frameworks. Admittedly, Mojolicious isn't really trying to be that kind of framework, and that's great...but, this one is such a common task. It feels weird to have to roll my own, if I want to make a somewhat traditional web application with it.
DBIx::Class is the only one I've really looked at. I also recall seeing a talk on Fey and Fey::ORM, given by the author, at YAPC or somewhere, and remember thinking it seemed really nice. But, I have never used any ORM heavily, so I'm still figuring it out.
Love DBIx::Class.. but it's not a good/perfect fit for Mojolicious by a long way.. it's blocking by nature and thus doesn't play too nicely if your aiming to write a non-blocking mojo app.
reply
For the few queries where you need async (most should be fast enough in the first place), there's no reason you can't use $rs->as_query to get hold of the SQL and bind values and then feed those into Mojo::Pg.
Is there such a thing as a non-blocking SQL query? Doesn't it always have to be wrapped up in something to make it non-blocking?
I think my question is: Is there an SQL ORM in any language that is non-blocking during queries, without the programmer having to wrap it in some sort of promise/callback/whatever? I really have no idea about ORMs, so I don't know anything about the state of the art. I'm trying to imagine what such a creature would look like...it seems like if your queries are going to potentially make you wait for any amount of time, you'd need to account for that at the caller side, even if things happen on the ORM side.
I agree. I think the main Perl workhorse modules that provide the best benefit for me are, in order:
DBIx::Class
Kavorka / Function::Parameters / Method::Signatures (take your pick)
Moose / Moo (or use Moops and get Kavorka above built in!)
Mojolicious
Notable mention: Path::Tiny (and Try::Tiny, but everyone should know that one).
It's taken me awhile to find the happy medium where I'm not sticking too much in DBIC ResultSet methods, but being able to define complex search methods that chain is awesome:
my $rs = Schema->resultset("Foo")->unprocessed->rows(100)->order_by([-desc=>'time']);
$rs = $rs->for_user($user) if $user;
$rs = $rs->recent_entries; # Limit to the last week
Makes my life much better, and makes it so much easier to change me schema as needed.
Comments
I've just started tinkering with Mojolicious, after spending some time playing with a variety of other frameworks in other languages (I'm starting a new web project, and wanted to make an informed decision about how to build it). Mojolicious gets so many things right in such a tiny package, I'm surprised more folks aren't using it or talking about it.
The real-time support is awesome; setting up Websockets is stupidly simple; coding non-blocking services is, I think, easier (at least more concise) than in Node.js (though it uses a similar callback model); testing is just perfect (Mojo has a user agent and DOM support, so you can write super concise tests for web services); building multiple outputs (like HTML for humans and JSON for API) for the same routes is excellent. So far, none of the frameworks I've looked at has been as concise or as...neat, I think might be the right word. So many things about it have me saying, "Now, why didn't someone think of that earlier?"
It's pretty tightly focused on just doing a few things really well, so it's not like a Rails, or even Django, experience...you have to make your own decisions about what ORM to use (or not to use an ORM), front end (though because it is agnostic about front end, you can use whatever you like pretty readily...so, React/Redux, Angular, whatever), and even nitty gritty stuff like authentication and accounts and such. I occasionally find myself wishing it had a little more batteries included, but mostly I like that it doesn't take days of doc/code spelunking to grasp the whole system.
Anyway, I'm not a Perl fanatic, though I like the language OK; especially in recent versions. So many little warts have gone away in recent years. But, the web service ecosystem in Perl is surprisingly strong and modern, given how unpopular it seems to have been in recent years. It's been a while since I really dug into what goes into building a new Perl system, and a lot of cool stuff has been completely off my radar. Mojolicious, in particular, is one of those things.
Well, there's a lot of helper modules[1] on CPAN (somewhat different than the ones linked in the article), so that may alleviate that concern a little bit.
Mojolicious is bar-non one of my favorite Perl technologies. :)
1: https://metacpan.org/search?size=20&q=mojox&search_type=modu...
Yeah, some of the modules are great. But, I mentioned my current paint point, which is user accounts. There's a couple of half solutions on CPAN, but nothing comparable to accounts support available in Rails or Django, or almost any of the other "big" frameworks. Admittedly, Mojolicious isn't really trying to be that kind of framework, and that's great...but, this one is such a common task. It feels weird to have to roll my own, if I want to make a somewhat traditional web application with it.
But, I agree...Mojolicious is a lot of fun.
Then why not put yours on CPAN?
If I end up building with Mojolicious (which seems likely), and I build some sort of generic user module, I will.
do you have something to recommend ?
used Rose::DB in the past, then I discovered SQLAlchemy and it's difficult to look back...
DBIx::Class is the only one I've really looked at. I also recall seeing a talk on Fey and Fey::ORM, given by the author, at YAPC or somewhere, and remember thinking it seemed really nice. But, I have never used any ORM heavily, so I'm still figuring it out.
1 point by ashimema 0 minutes ago | edit | delete
Love DBIx::Class.. but it's not a good/perfect fit for Mojolicious by a long way.. it's blocking by nature and thus doesn't play too nicely if your aiming to write a non-blocking mojo app. reply
For the few queries where you need async (most should be fast enough in the first place), there's no reason you can't use $rs->as_query to get hold of the SQL and bind values and then feed those into Mojo::Pg.
Is there such a thing as a non-blocking SQL query? Doesn't it always have to be wrapped up in something to make it non-blocking?
I think my question is: Is there an SQL ORM in any language that is non-blocking during queries, without the programmer having to wrap it in some sort of promise/callback/whatever? I really have no idea about ORMs, so I don't know anything about the state of the art. I'm trying to imagine what such a creature would look like...it seems like if your queries are going to potentially make you wait for any amount of time, you'd need to account for that at the caller side, even if things happen on the ORM side.
I'd need someone suggesting anything other than DBIx::Class to present some ironcast arguments for that choice
I agree. I think the main Perl workhorse modules that provide the best benefit for me are, in order:
DBIx::Class
Kavorka / Function::Parameters / Method::Signatures (take your pick)
Moose / Moo (or use Moops and get Kavorka above built in!)
Mojolicious
Notable mention: Path::Tiny (and Try::Tiny, but everyone should know that one).
It's taken me awhile to find the happy medium where I'm not sticking too much in DBIC ResultSet methods, but being able to define complex search methods that chain is awesome:
Makes my life much better, and makes it so much easier to change me schema as needed.