The /client.config endpoint must query the services health endpoint

[paulodiniz]

We must query the health endpoint for each service returned on the controller api call to check the status

[paulodiniz]

After a call with @lucapette we came up the following proposal

The return /components stays as it is now

{
  "components": [
    "api-communication",
    "media-resolver",
    "integration-webhook",
    "api-admin",
    "api-websocket",
    "frontend-chat-plugin",
    "frontend-ui",
    "sources-chat-plugin",
    "sources-facebook",
    "sources-google",
    "sources-twilio"
  ]
}

The /client.config transforms the output, but it doesn't check the status

{
  "components":  {
     "sources-facebook": {},
     "sources-google": {}
  }
}

Benefits: By removing the enabled field on the return, we would remove the overhead of having and checking a service healthcheck for each component

What do you think?

cc @lucapette @chrismatix @AitorAlgorta

[chrismatix]

How would the output of the status command work then? Currently, it shows all components and whether or not they are running.

While I think this is a fast way to make this work, I would re-iterate the proposal I made on Slack. Instead of dumbing down the endpoint, we can make a better distinction between apps (user runnables in our cluster) and components (things you can configure in the airy.yaml i.e. a source).

So to make /client.config useful for both use cases we could have /components return something like this:

{
  "sources-facebook-connector": {
    "enabled": true,
    "component": "sources-facebook"
  },
  "sources-facebook-events-router": {
    "enabled": true,
    "component": "sources-facebook"
  },
  "api-communication": {
    "enabled": true,
    "component": "api-communication"
  }
}

• The component identifier can be set as a Kubernetes annotation on the deployments/statefulsets
• The frontend can very easily .reduce on the component identifier to get the view that it needs

It's also worth considering renaming enabled to running because it more accurately reflects the check that the endpoint is doing.

Since we are already going for introspection it makes more sense to me to follow through with it.

[AitorAlgorta]

it’s easier to find for us the right thing if the component name is they key, like it was in the beginning

"source-facebook": {
    "enabled": true,
    "healthy": false
}

[chrismatix]

@AitorAlgorta that's true but long term it makes more sense if the endpoint reflects the state of the system more precisely. Say for instance you want to display exactly which apps are failing and why in the UI.

Plus transforming the above payload is as simple as:

Object.keys(payload).reduce((result, key) => {
    const {healthy, enabled, component} = payload[key];
    return {
        ...result,
        [component]: {
            enabled,
            healthy: result[component] ? result[component].healthy && healthy : healthy
        }
    }
}, {})

By keeping the response generic it will be easier to adapt to new requirements on the client.

[AitorAlgorta]

yeah I am good with both options actually. I understand that this one makes more sense and that one extra step to have the desired structure is not a big deal.