Use ports to route to canisters when using `dfx start`

[nmattia]

Currently, running dfx start will start a replica-ish executable that will proxy HTTP requests to installed canisters based on the value of ?canisterId=.... This is not ideal for the following reasons:

• The canister IDs are dynamic and not generally known before the canisters are installed. This means that if I have another local service (think: e2e tests) that needs to connect to a given canister, I need to always update the URL to connect to. While canister IDs seem to be always assigned in the same order, this is not documented nor is it robust, and breaks if I don't start from a clean state (e.g. with no canisters installed).
• The query parameters need to be forwarded to all calls. This is an issue if I have e.g. a multi page webapp that performs redirects. For instance, the webapp may re-route to / when the user logs out, which will break because of the missing ?canisterId=....

In the nns-dapp we are working around this by using a proxy that maps (stable, known) ports to canister -- by name. In particular, our end-to-end test runner will start by looking up the canister IDs in .dfx/local/canister_ids.json and the replica host in dfx.json and will then route requests appropriately. The test suite can then use localhost:<stable port> to reach a given canister. It would be great to have something similar baked into dfx as opposed to using query parameters.

[ninegua]

You can already use http://<canister-id>.localhost:8000 to connect to the frontend canister.

[paperchase4218]

How do I use it where's it at?

[nmattia]

Hi @ninegua , thanks for the info! I didn't know. Unfortunately this still requires knowing the canister ID, which is created dynamically, am I correct? Also can you clarify what you mean by "the frontend canister"? Does that only work if you have exactly one canister of type frontend?

[bitdivine]

@ninegua Thanks! I didn't know either. I was wondering why we weren't using subdomains of localhost. I know they are unsupported on old linux but I tested some recent-ish machines and subdomains resolved correctly on all of them. Didn't get as far as testing Mac.

[sesi200]

I think we can consider this handled. Please reopen if not.

[nmattia]

@sesi200 unfortunately not, there is still no good story for connecting to other canisters (locally) without relying on the canister ID generation sequence, or looking up non-public dfx data (canister_ids.json) -- the latter which anyway won't working unless you've first creating the canisters.

Even @ninegua's suggestion (which only works in some browsers like chrome and not with e.g. curl & al) does not resolve the issue since you still need to know the canister ID:

Unfortunately this still requires knowing the canister ID, which is created dynamically, am I correct?