Solve contextPath problem across multiple types of deployments

[tarelli]

1. [ ] Analyse all places in the code where the context path is currently used and how it relates to each deployment (e.g. in this deployment we have this contextpath, this is where the static files are served, this is where geppetto is served, etc.)
2. [ ] Review current PRs which seems to work for JupyterHub and the Java deployment https://github.com/openworm/org.geppetto.frontend.jupyter/pull/57 https://github.com/openworm/org.geppetto.frontend/pull/859
3. [ ] Remove hardcode of org.geppetto.frontend from jupyterGeppetto reading it from the GeppettoConfiguration.json instead
4. [ ] geppetto should be served at the contextPath even for jupyter/python deployments while now it always comes from the root
5. [ ] When in JupyterHub we have /user/asofsfoja/ that is currently also treated as the contextPath. This overcomplicates the logic because whatever is in GeppettoConfiguration.json is not "for sure" the contextPath anymore (as there might be something else afterwards, e.g. "/user/aofiafh/") and in the code we have string manipulations to identify the last slash and similar. A way to solve this might be to have something like a static cotextPath, i.e. what we find in the configuration, and a "dynamic" one that might or might not exist depending on the deployment and we should have a linear way to fetch whether this exists or not.
6. [ ] The logic in the client to figure out where to get resources from is probably overcomplicated due to the two points above.
7. [ ] Reconsider all the above under the light that maybe it shouldn't be the application (ie GeppettoConfiguration.json) the single source of truth for where things like the contextPath are configured but it could be argued that that should really just match the deployment. In that case how can we have a single source of truth deployment wise?

[tarelli]

Things I don't like

Geppetto.Main.js, line 106. String concatenation, checking for slash and in that case replacing the port??

                var host = GEPPETTO.MessageSocket.protocol + window.location.host + '/' + GEPPETTO_CONFIGURATION.contextPath + '/GeppettoServlet';
                if (GEPPETTO_CONFIGURATION.contextPath == "/") {
                    host = GEPPETTO.MessageSocket.protocol + window.location.host.replace("8081", "8080") + '/GeppettoServlet';
                }

Update Another thing I don't like, in Jupyter Hub (eg HNN): "contextPath": "org.geppetto.frontend/",

in Java "contextPath": "org.geppetto.frontend" (eg VFB),

Why the difference? Are they both valid now?

[filippomc]

Some thoughts after some merging of the above commits within a Jupyter application.

• this new situation with JupyterHub made clear is that, thinking in general, the contextPath is not something that is driven by the client, nor the application, but it's something that's coming from the host.
• Usually web apps don't care about this base path because that's something that can been taken care of in the host configuration (e.g. with apache, mod_rewrite rules).
• With JupyterHub we are relying on the Tornado server, which does not have this capability, so we have to deal with the problem within the application.
• Nor we have that on the JS client, which needs to make the Websocket and REST calls to the correct backend.
• The contextPath is misleading and not sufficient: it's indicating the relative path for the webapp files only . The base application path is something different. The complete url for client resources should be thought as: PROTOCOL://HOST:PORT/BASE_PATH/CONTEXT_PATH/FILE_PATH, while the server APIs are like: PROTOCOL://HOST:PORT/BASE_PATH/API_PATH. EDIT: the context path it's also used to call the default geppetto services. That complicates things, separating the paths for client files and APIs would be advisable anyway to prevent name clashes and allow the client to be served separately.
• The mere presence of the global variable GEPPETTO_CONFIGURATION is dangerous. Yes we know it comes from GeppettoConfiguration.json, but everyone can modify it - and in this case we need to modify it. So we are not sure of what's happening.

With this premises I think that it's best to get rid of contextPath into the application configuration and any other host parameters given to the application.

Proposal:

• The configuration instead of being loaded into a global variable is loaded when needed by service modules. For instance, we compose a url for a client resource with GeppettoPathService.staticUrl(myPath). That service may load the configuration at first but then has full control of what happens with the configuration, leaving freedom to implement whatever behaviour at runtime leaving everything clear and safe.
• When the client loads, it can infer the base path from window.location.path, as in the patch proposed (see https://github.com/openworm/org.geppetto.frontend/blob/development/src/main/webapp/js/pages/geppetto/GEPPETTO.Main.js). This logic should be moved into the Service above, which would learn the path at the first page load
• The same can be achieved from Tornado in the Jupyter backend: we can build the application routes dynamically at the first page request.

[tarelli]

Flavours that need to be tested:

• [ ] Development environment with files served from webpack in Java, what we start right now using npm start
• [ ] Development environment with files served from webpack with Jupyter, what we start right now using npm ....:watch
• [ ] Java production environment with a context path, e.g. org.geppetto.frontend
• [ ] Java production environment with a root context path, e.g. /
• [ ] Jupyter Notebook with a context path, e.g. org.geppetto.frontend
• [ ] Jupyter Notebook with a root context path, e.g. /
• [ ] Jupyter Hub with a context path, e.g. org.geppetto.frontend
• [ ] Jupyter Hub with a root context path, e.g. /
• [ ] Geppetto Django applications (see template)

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.