[Idea] Split core Grafana interactions into its own node module

[stephenyeargin]

In its present state, this Hubot package builds all of the requests to a Grafana instance and handles the interaction with the user. Ideally, these should be two separate modules.

node-grafana (new)

Low-level HTTP(S) request library that handles authentication and common queries against the API (retrieve a list of dashboards, grab a specific dashboard's data, build the URLs for images, etc.).

grafana-hubot (this package)

A much lighter-weight wrapper that uses a configured instance of node-grafana to query the API. It also would handle the various adapters for uploading images, such as S3, Slack, HipChat, etc.

---

This should cut down the total lines of code in this package while giving Hubot and other node developers an alternative to relying on the conventions of this package.

/cc #47

[stephenyeargin]

Alternatively, if somebody else creates one, make this package use it. 😀

[KeesCBakker]

@stephenyeargin, I'm looking at swapping some of the features to a GrafanaClient to separate what is happening in the bot. But doing so will give the code a massive overhaul. Until now, all the tests are working. Before I continue I would love to hear your opinion if I'm on the right way...

Can you give this one a look? KeesCBakker#1

[stephenyeargin]

The only two things we need out of the robot object are logger and http.

• For logger, we can likely replace it with a peerDependency on pino. Hubot's own implementation is rather basic.
• The http wrapper would be a bit more complicated, but we handled that similarly in feat: swap out obsolete request package for node-fetch #162 by replacing it with the more modern Fetch API.

In all this time, there still isn't an official SDK published to NPM. You can go to the Swagger documentation and generate a ZIP file of one, but that's a lot of baggage for the handful of endpoints we use. Similar story if you wanted to use one of the published third-party packages. They all appear to be older and not maintained.

• https://www.npmjs.com/package/grafana-http-api
• https://www.npmjs.com/package/grafana-http-client

All that to say, I think you're on the right path here. We would need to make sure we add the class to the files argument in package.json so that it's included at release. Only noting that because it is for sure something I would forget to do.

From there, you can mock the GrafanaClient methods when writing tests for the Hubot script, and then mock the actual calls when writing a separate test for the client itself. That would decouple things a bit, and you can likely use existing fixtures for both test suites. That would let you leave anything that needs to speak Hubot's DSL (e.g. room name, message parsing, etc.) in the main file, and everything that needs to talk and to and understand Grafana in the client file.

[KeesCBakker]

It took some time and a lot of mental gymnastics, but I think I now have a GrafanaClient that only depends on the robot.http and robot.logger. To get some hints on types I added some JSDocs and types packages. I also refactored fetch away, as we already have the robot.http to do the heavy lifting.

Class can be viewed here: https://github.com/KeesCBakker/hubot-grafana/pull/1/files#diff-a9f71d2f2ecf00aa3fa557f10b2c5dcdc1779e356082ec556a85b638cc50e900

Now I need to check if this works for my setup (Slack/S3). So far, all the tests are working 😄 .