Local resources still being requested for WNS despite config-prod

[ccamrobertson]

Despite using config-prod.yml via yarn start, it appears that local services are still being requested on the WNS page. While log requests work as expected -- that is, they are routed to the correct endpoint -- getStatus and queryRecords called from console/wns.js fail.

I've added extra logging in src/hooks/registry.js to verify this --

export const useRegistry = (config) => {
  const endpoint = get(config, 'services.wns.server');
  assert(endpoint);

  console.log(`Endpoint:  ${endpoint}`);
  console.log(`Services: ${get(config, 'services.wns.server')}`);
  console.log(`Routes: ${get(config, 'routes.wns.server')}`);  
  console.log(`Service URL: ${getServiceUrl(config, 'wns.server')}`);  

  const registry = new Registry(endpoint);

To test locally, I recommend using the tel-apache branch.

1. Ensure that wns is not running on your system (this helps to clarify which endpoints are failing).
2. yarn
3. yarn start
4. Navigate to https://localhost/console/wns and open the JavaScript console. You may need to refresh as the failures only occur once.

My current guess is that the getStatus and queryRecords calls are never routed through registry.js but rather handled directly by registry-client.

[ccamrobertson]

I was incorrect that getStatus and queryRecords calls are not routed through registry.js; they are. With this in mind I decided to hard code an endpoint that is fed into the registry-client constructor:

Line 22 of src/hooks/registry.js: const registry = new Registry('https://localhost/dxos/wns');

This yielded interesting results; registry-client took the endpoint, sliced off dxos/wns and replaced it with graphql. Looking at src/index.js in registry CLI this makes sense.

This leads to a couple of thoughts; the repeating logs call does not fail because it's called directly against the wire CLI (despite being routed through registry.js) and we either need to change the routes fed into registry-client to include the full path (e.g. https://xbox.local/dxos/wns or likely make changes in registry-client to accomodate.

[ccamrobertson]

The fix for this is two parts:

• [x] Grab window.location.hostname, feed this into registry.js and add to getServiceUrl
• [x] Amend registry-client to either not check for /graphql at all or check for both /graphql and api.

In the meantime we can keep wns at /dxos/wns/graphql rather than API to keep registry-client happy.

[ccamrobertson]

See https://github.com/wirelineio/registry-client/issues/42 for second part of fix.

[ccamrobertson]

https://github.com/dxos/dashboard/pull/47