When I run jitsi-meet in dev mode, what is running locally?

chriswolske · May 14, 2023, 3:53am

I downloaded the source and am running jitsi-meet on 127.0.0.1:8080, and I’m assuming that is only the meet application and a basic web server (when looking at the architecture diagram: Architecture | Jitsi Meet).

I’m assuming it is using a remote prosody server, but I’m wondering if that’s hard-coded and/or what ports it is running over. I assumed port 5280 (based on Self-Hosting Guide - Manual installation | Jitsi Meet), but looking at tcpdump for that port didn’t show any outbound traffic.

If the development instance is running xmpp/jicofo/vb locally, that’s fine, I just didn’t think that’s how it would work.

emrah · May 14, 2023, 10:02am

jitsi-meet, prosody and jicofo are on the same server in a typical setup. Prosody’s 5280 is set as an upstream in nginx conf

github.com

jitsi/jitsi-meet/blob/master/doc/debian/jitsi-meet/jitsi-meet.example#L8


      
          server_names_hash_bucket_size 64;
          
          
types {
          # nginx's default mime.types doesn't include a mapping for wasm or wav.
              application/wasm     wasm;
              audio/wav            wav;
          }
          upstream prosody {
              zone upstreams 64K;
              server 127.0.0.1:5280;
              keepalive 2;
          }
          upstream jvb1 {
              zone upstreams 64K;
              server 127.0.0.1:9090;
              keepalive 2;
          }
          map $arg_vnode $prosody_node {

damencho · May 14, 2023, 1:00pm

The make dev just runs a proxy server locally so you can use the local UI code and everything else is used from a remote server. It works by default with a server we have setup with limited capabilities, but you can always setup and use yours:

github.com

jitsi/jitsi-meet/blob/63927db9e4f692070e96004fbf4629113ea612bf/webpack.config.js#L15


      
          const { join, resolve } = require('path');
          const process = require('process');
          const webpack = require('webpack');
          const { BundleAnalyzerPlugin } = require('webpack-bundle-analyzer');
          
          
/**
           * The URL of the Jitsi Meet deployment to be proxy to in the context of
           * development with webpack-dev-server.
           */
          const devServerProxyTarget
              = process.env.WEBPACK_DEV_SERVER_PROXY_TARGET || 'https://alpha.jitsi.net';
          
          
/**
           * Build a Performance configuration object for the given size.
           * See: https://webpack.js.org/configuration/performance/
           *
           * @param {Object} options - options for the bundles configuration.
           * @param {boolean} options.analyzeBundle - whether the bundle needs to be analyzed for size.
           * @param {boolean} options.isProduction - whether this is a production build or not.
           * @param {number} size - the size limit to apply.
           * @returns {Object} a performance hints object.

chriswolske · May 14, 2023, 4:40pm

const devServerProxyTarget
    = process.env.WEBPACK_DEV_SERVER_PROXY_TARGET || 'https://alpha.jitsi.net';

Exactly what I was looking for – thanks!

It looks like this alpha.jitsi.net has a 5 minute time limit on conferences, for example… not a problem for me or this level of testing.

chriswolske · May 14, 2023, 6:40pm

and a follow-up question:

If my project actually gets to a point where I want to go live with a new frontend app, but I don’t want to deal with hosting any of the backend components, I’m assuming I can just point the app to an 8x8 Proxy Server (paid solution)? Or am I oversimplifying that?

chriswolske · May 14, 2023, 7:02pm

Just to confirm that jitsi documentation was not lacking (I just wasn’t reading the right things), this is where the devServerProxyTarget is described in the Developer’s Guide:

(my bad)

damencho · May 14, 2023, 10:09pm

You need to either host your own deployment, instructions on how to install it: https://jitsi.org/qi. Another option is to use JaaS: https://jaas.8x8.vc/.