Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"
 
PerlMonks  

Mojolicious::Lite and Webperl

by frazap (Monk)
on Apr 09, 2019 at 12:31 UTC ( [id://1232348]=perlquestion: print w/replies, xml ) Need Help??

frazap has asked for the wisdom of the Perl Monks concerning the following question:

Hi there

I'm refering to this Run Perl 5 in the Browser!

I wrote a small Mojolicious::Lite script, that is one page with a form to send select statements to a database (on a server somewhere in my organization net). I packed the script with PAR::Packer pp and got the thing working on anyone's pc.

Now, could I embed this script in a browser having the server load with the script in the web page ?

Would Webperl be a way to go ?

Thanks

frazap

Replies are listed 'Best First'.
Re: Mojolicious::Lite and Webperl
by haukex (Archbishop) on Apr 09, 2019 at 13:03 UTC

    As discussed in Corion's reply and my follow-up, getting modules into WebPerl takes a bit of work, especially modules with XS/C code, and sockets are a much more complex topic. The typical way to approach this kind of thing is to have a server (in this case probably the Mojolicious::Lite app) communicate with the browser with e.g. HTTP+JSON. The repository contains an example of using jQuery's ajax method here and a native XMLHttpRequest here - the latter example is a synchronous request, which is not typical, but since translating JavaScript to Perl is fairly straightforward, many of the examples of using XMLHttpRequest can be easily translated.

    In your reply here you said:

    Even php is banned for the end user.

    I'm not sure what you mean here - do you mean you can't even use PHP on the server side? That'd be a pretty strange restriction, given that based on your question, apparently your database server would be reachable from the clients?

    I think if you re-think the architecture a little bit, the whole thing is doable with WebPerl: Instead of trying to put everything in the browser, you can split it up: One Perl script, running locally, acts as the webserver (Mojolicious::Lite), and it can also launch the browser, which accesses that local webserver, and the webserver serves up a HTML page with an embedded WebPerl script, acting as the GUI, which can then communicate with the local webserver as mentioned above. While the WebPerl script is pretty much sandboxed in the browser, the local webserver can do anything that a normal Perl script on the machine can, i.e. access local files, open network connections, etc.

      I'm not sure what you mean here - do you mean you can't even use PHP on the server side?

      Web pages have to be edited with ModX revolution, and php code can't be added using this tool (as it is configured). Running the mojolicious lite script from a pc, with starting the script at pc launch, would be a poor man's server, better this is better then nothing. I can link to this Mojolicious::Lite page using the pc IP address.

      you can split it up: One Perl script, running locally, acts as the webserver (Mojolicious::Lite), and it can also launch the browser, which accesses that local webserver, and the webserver serves up a HTML page with an embedded WebPerl script, acting as the GUI, which can then communicate with the local webserver as mentioned above.

      do you mean: anyone interested would have to download the packed script ? That would not work for Mac or *nix users.

      Why using WebPerl to build the GUI ?

      Or do I misunderstand ?

        do you mean: anyone interested would have to download the packed script ?

        Everything could still be packed into one distribution: the local webserver script plus the files it serves to the local browser, which would include the WebPerl code.

        Why using WebPerl to build the GUI ?

        You don't say if you've already built a GUI, and if you have, what toolkit you used? WebPerl allows one to basically replace JavaScript, so it's possible to write a fully interactive GUI in the browser, using Perl instead of JS. If you've already got a GUI written with a different toolkit, then it's currently not possible to just put that into WebPerl and have it work.

        It's unfortunately also currently not possible to just stick any interactive command-line script into WebPerl, because reading from STDIN is blocking, and doing blocking I/O, while not impossible, requires some pretty complex workarounds. (I've got this in the back of my head, and if I see some possible workarounds showing up, I'd see if I could implement those.) So while some Perl code can be copied directly into WebPerl, other Perl code requires one to think about the limitations inherent in the browser environment.

        There are now two examples available:

        • WebPerl Basic GUI Example - the local web server is Plack, and it shows how to access a DBD::SQLite database on the local machine; the frontend (in the browser) is written in Perl without the help of any JavaScript libraries.
        • WebPerl Advanced GUI Example - the local web server is a Mojolicious::Lite app, and the frontend is of course also written in Perl, but this time including Bootstrap and jQuery. (This example doesn't implement anything fancy on the server side, it just shows how to communicate with the server via JSON.)

        I've implemented both so they can be packed by PAR-Packer (tested on Linux).

Re: Mojolicious::Lite and Webperl
by Corion (Patriarch) on Apr 09, 2019 at 12:35 UTC

    What server would you serve your WebPerl+script from, and why can't that server directly serve your Mojolicious::Lite app?

    Also, making outgoing TCP connections (like which are needed for any networked database driver) is not implemented in WebPerl (I think).

    Another problem is building WebPerl with the database driver. WebPerl is a statically linked Perl and that means any module that needs a C compiler (like almost any DBD:: module) needs to be compiled into that Perl at build time.

      making outgoing TCP connections (like which are needed for any networked database driver) is not implemented in WebPerl (I think).

      Only partially: Emscripten supports WebSockets, and it exposes these via the C sockets API (see also), so actually Perl's sockets API is able to access it. On the server side, one would need a WebSockets proxy (e.g. websockify), assuming the server doesn't support sockets natively. This is as far as I got playing around with it on the WebPerl client side. However, the big problem is that these sockets are required to be non-blocking, and so the database driver would need to be implemented as such, which is a big ask.

      Thanks for replying corion

      The server is my organization's. It's surely Apache, and since they build mobile responsive pages, they are very restrictive on what can be made, what technology can be used.

      Even php is banned for the end user.

Re: Mojolicious::Lite and Webperl
by LanX (Saint) on Apr 10, 2019 at 16:50 UTC
    This sounds like an XY Problem for me.

    Distributing a web application to every user to be capable to run an SQL query means that the access to the SQL-Server is exposed to everybody who looks into the HTML sources.

    If you can't install a web application on your companies apache why don't you try to run Mojolicious standalone on another "private" host?

    You can put a static page on your apache which redirects to this private server.

    Your application doesn't seem to be heavy enough to exclude being run in Mojo's own webserver.

    I really like seeing more apps running into webperl but this sounds weird.

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

      Thanks for commenting LanX

      We did what you outlined above: run the mojolicous daemon on a virtual server on a Windows pc, and link to the generated search page from the main site.

      The script is in my my scratchpad, and the interface is a just a form web page.

      And, yes: using one app that would be run in the browser using WebPerl would have the same problem as distributing an exe that would be run on every interested user'pc: how to prevent users from getting access to the mysql server directly.

      frazap

        > We did what you outlined above:

        So your problem is solved now?

        Cheers Rolf
        (addicted to the Perl Programming Language :)
        Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://1232348]
Approved by haukex
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others having a coffee break in the Monastery: (9)
As of 2024-03-28 18:48 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found