General Async Question regarding use-case.

[ajmetz]

Hello,
I have yet to dip my toe into the Mojolicious Async waters,
and I'm curious....

QUESTION: Does an Async Mojolicious app have to be entirely async to be worthwhile, or does async work too in an approach where you've an aspect of your mojolicious app that's non-blocking, and other parts that are blocking?

Or is that a dumb question, due to what practically happens when you begin coding this stuff? I haven't begun such a project yet so lack insight. Maybe it's relatively easy to make every aspect non-blocking? I'll figure it out when I try, ^_^.

While I can imagine a hybrid app, might be a blocking webapp with a non-blocking queue;
Or a blocking website, with a non-blocking async chat box on a page,
I'm also curious about CPAN modules.

So far, my webapps have been using the Template::Nest cpan module for nested html layouts, then rendered as text/html by Mojolicious. Do you need to chose async friendly cpan modules too? Or is it no big deal if your app uses some non-async modules in places? Am not presently aware of how to do nesting in ep or tt2, hence using Template::Nest. I'm guessing I could await a Template::Nest layout, but since there's nothing else to do after that but render the page, I assume it might as well be blocking.

[false200]

@ajmetz not a dumb question. Hybrid is normal, you don't need the whole app async.

Async is worth it where you're waiting on I/O and want the server doing other work meanwhile: outbound HTTP (Mojo::UserAgent non-blocking), websockets, chat, long polling, fan-out to multiple backends in one request. Blocking template rendering with Template::Nest is fine. If the only thing left after the layout is render, blocking there is the right call, await wouldn't buy you anything.

Rule of thumb: blocking code in a request handler blocks that worker until it finishes. Short stuff (templates, simple DB, JSON) — nobody cares. Long stuff (big CPU, slow external calls via blocking modules), either use the Mojo async equivalent, Mojo::IOLoop::Subprocess, or accept that you need more hypnotoad workers.

CPAN: you don't need async-everything. Use non-blocking paths for I/O you want concurrent (Mojo::UserAgent, Mojo::Promise, async/await on routes that need it). Random blocking CPAN modules in the middle of a handler are fine if they're fast. If something does blocking I/O internally and you call it from an otherwise-async route, you've just blocked the event loop for that worker — that's the thing to watch for.

Practical split that matches what you described:

• normal pages → blocking Template::Nest render, done
• chat box / websocket / background fetch → async route, maybe render_later, non-blocking UA
• heavy queue work → subprocess or separate worker process, not inline in the web handler

So yeah, start hybrid. Make the slow/concurrent bits non-blocking, leave the rest blocking until you have a reason not to. You'll feel quickly which routes stall under load.

[ajmetz]

Super grateful for the response - that reads as a practical guide on how to make the decisions or judgement calls in this regard. I've read a lot of the concepts of async, and the above is the first practical advice on where to be using it that I've encountered - and admittedly, I may be under-read on the subject. That said, yeah, I'll try starting hybrid and take it from there, =). Many thanks!

[false200]

Glad it helped. Good luck with it.