Can we run everything on the same port?

[jnicklas]

One thing that I've been thinking about: BigTest currently uses 4 or 5 different ports:

1. command server
2. connection
3. manifest server
4. proxy server (also serves the agent)
5. app server [optional]

I am sure we do not really need to run the first three on different ports, and I'm pretty sure we can even map the manifest server to the same port. The app server needs to be running on a different port obviously.

The way this would work is basically through routing like this:

• __bigtest/api => command server/GraphQL API
• __bigtest/connection => WS connection for agent
• __bigtest/manifest => serve generated manifest, this is a bit tricky since we need to prefix the paths in the generated bundle
• __bigtest/agent => serve static agent from agent package
• * => any other path goes to the proxy server

This way BigTest itself would only occupy one single port with possibly an additional port for the app server.

[jnicklas]

cc @cowboyd

[cowboyd]

It seems like a sound idea. I have two thoughts that occur:

1. I think we're going to want to make this type of mechanism extensible so that plugins can run their own servers without any special consideration from the orchestrator.
2. It still feels like the (a) proxy, (b) static agent html, and (c) manifest belong at a separate origin. For example, does it make sense for a running test case to have access to the api or the connection server on a same origin basis? What does that mean for node agents, and iOS agent? For example, should the iOS agent ever need to see or load manifests from the web agent?

However, there's no reason we couldn't have a general mechanism that allowed plugins to allocate an entire origin, and then allocate urls within that origin. If everybody was configuring themselves over this central registry of origins and urls, then moving services around, splitting them or consolidating them can at least be straightforward. Bigtest can handle port allocation and configuration and your extension code never needs to worry about things like url discovery.... I like this idea of having something like a rails router, except including the origin too!

[jnicklas]

That's a good point, plugins will need to be able to load custom mappings somehow. As for routing, we currently handle this through express, and it doesn't feel like we need to reinvent the wheel here.

I just hit another reason to do this: if an error occurs in the test files, its details won't be reported to the uncaught error event, it will just show up as "script error", since errors from other origins cannot be "seen" in a global error handler for security reasons. As far as I can see, the only way of solving this is to move the manifest onto the same origin.

[cowboyd]

I think moving the manifest onto the same origin really makes sense since it feels like we're learning that manifest bundling highly coupled to platform, and eventually might be completely under the responsibility of the agent or driver.

For example, there is absolutely no need to concatenate down to a single bundle file for the node driver, and certainly no need to start a server to serve that single asset. That's behavior particular only to web agents.