So, I'm currently working at a feature where I need to respond with multiple dashboards from multiple places. I don't have to option to just create that dashboard and return it. The "easiest way" to implement the feature is to do some rewriting of the package into 4 components: the bot, an adapter, a service and a client.
┌────────────────────────────┐ ┌────────────────────────┐ ┌────────────────────────┐
│ BOT │ │ ADAPTER │ │ CUSTOM RESPONDER │
│ │ │ │ │ │
│ handles request from Hubot ├───► respond to a specific ├────► influence the way the │
│ responsible for response │ │ chat platform │ │ response is written │
│ formatting │ │ │ │ │
└──────────────┬─────────────┘ └────────────────────────┘ └────────────────────────┘
│
┌──────────────▼─────────────┐
│ SERVICE │
│ │
│ business rules for │
│ querying of dashboards │
└──────────────┬─────────────┘
│
┌──────────────▼─────────────┐
│ CLIENT │
│ │
│ interaction with the │
│ Grafana API over HTTP │
└────────────────────────────┘
The service should return small DTOs so we can build these new types of integrations.
Way forward
I think we should do the following:
Check if we can refactor the GrafanaClient as not to use Hubot HTTP, but something regular like fetch. We've tried in the past, but could not get it to work because of the testing (if I remember correctly).
Check if we can refactor the a GrafanaService out of the bot that interacts with the bot based on DTOs.
Find a solutions to GrafanaClient creation. Sometimes the client uses data from the channel. This might be fixed by introducing a GrafanaClientFactory that will help to determine the right settings for the client.
So, I'm currently working at a feature where I need to respond with multiple dashboards from multiple places. I don't have to option to just create that dashboard and return it. The "easiest way" to implement the feature is to do some rewriting of the package into 4 components: the bot, an adapter, a service and a client.
The service should return small DTOs so we can build these new types of integrations.
Way forward
I think we should do the following:
GrafanaClient
as not to use Hubot HTTP, but something regular likefetch
. We've tried in the past, but could not get it to work because of the testing (if I remember correctly).GrafanaService
out of the bot that interacts with the bot based onDTOs
.GrafanaClient
creation. Sometimes the client uses data from the channel. This might be fixed by introducing aGrafanaClientFactory
that will help to determine the right settings for the client.setResponder
it is easier for users to influence the way the dashboard is formatted (so we don't need to use middelware like https://keestalkstech.com/2022/11/grafana-i-want-slugs-back-for-my-hubot-%f0%9f%98%ad/#make-hubot-understand anymore.