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.