title: Most viable WebSocket/Perl solution
body: <p>The company I'm working at uses Perl for all "backend related" stuff. However, we would like to use some real-time communication between server-processes and connected clients via browser.</p>
  
  <p>We are also using Apache as Webserver with <em>mod.perl</em>. So that is my first question, I don't see any practical way to combine a WebSocket-Server in that constelation. Maybe there is one I didn't found yet?</p>
  
  <p>The only thing which really works serious about that topic, is <em>Mojolicious</em>. However I'm not that experienced with that yet, so I'd be happy if someone could state if I can use that in my  current mod-perl environment. I think I also would have to let this run as <em>standalone webserver process</em>, No?</p>
  
  <p>Which brings me to my second question. What is the best practice, if you have multiple perl files, which do certain things running on <em>Apache/modperl</em>, but you want to keep all your connected users informed about things. What I mean is, all these scripts are accessed via <em>XHR</em>, but some actions require other users to get informed. Currently, we do a classic <em>ajax polling</em>.</p>
  
  <p>The problem I'm struggling around with is, that if there is a <em>dedicated websocket server</em>, which runs independently, all those scripts would need to somehow communicate with this process as well right ? How would one do that? Pipes? Sockets? Shared memory ?</p>
  
  <p>Theoretically, if I would choose to go with such an independent <em>ws server</em> solution, I could write it in any language right? Could even be Ruby or Node. I'm just wondering if that is the best way or if there is a good solution which is more integrated in existing perl/modperl constructs.</p>
  
  <p><strong>TL;DR</strong><br>
  Is it best practice to have a <em>standalone, independent web-socket server</em> which communicates with the rest of your <em>Apache/modperl</em> scripts aswell as with its connected clients ?</p>