Vous en avez assez de rechercher Slack, GitHub et Google Drive séparément ? Faites tout en même temps en SQL

Vous connaissez l’exercice : les mots que vous recherchez peuvent se trouver dans Slack, ou GitHub, ou Google Drive, ou Google Sheets, ou Zendesk, ou… la liste est longue. La recherche dans ces silos est une frustration courante. Cela devrait être sans friction, et ce tableau de bord Steampipe le rend ainsi.

Ce n’était pas mon premier rodéo. J’ai commencé ce voyage en 1996 et j’ai revisité l’idée périodiquement. En 2018, j’ai écrit sur une version qui était l’exemple classique de The Simplest Thing That Could Possiblement Work : une page Web qui rassemble les URL de recherche de divers services et visite chacun dans son propre onglet. Aussi bête que cela puisse paraître, c’était assez utile pour s’habituer un peu, et pas seulement par moi.

Bien sûr, je voulais utiliser les API sous-jacentes, normaliser les résultats et les fusionner dans une vue commune. Mais l’effort requis pour embrouiller toutes les API a rendu ce projet plus difficile qu’il n’en valait la peine. Si vous avez déjà fait ce genre de choses, vous savez que la plupart des services fournissent des API de recherche ainsi que des adaptateurs pour votre langage de programmation préféré. Mais chaque service aura sa propre façon d’appeler l’API, de paginer les résultats et de les formater. Ces différences créent des frictions que vous devez surmonter afin de travailler avec les résultats de manière cohérente.

Lorsque les querelles d’API deviennent sans friction, beaucoup de choses deviennent possibles. Une métarecherche efficace en fait partie. Steampipe vous évite d’avoir à appeler des API, à paginer des résultats et à décompresser des objets JSON. Il appelle les API pour vous et diffuse les résultats dans des tables de base de données afin que vous puissiez vous concentrer entièrement sur l’utilisation des données. Cela résout le plus gros problème auquel vous êtes confronté lors de la création d’un tableau de bord de métarecherche.

Convergence sur un schéma

Le défi suivant consiste à lier les résultats de la recherche à un schéma commun. SQL est un excellent environnement pour le faire. La requête qui pilote le tableau de bord affiché dans le screencast comprend trois strophes que vous n’avez pas besoin d’être un assistant SQL pour écrire. Ils suivent tous le même schéma que celui-ci pour rechercher les problèmes GitHub.

select
   'github_issue' as type,
   repository_full_name || ' ' || title as source,
   to_char(created_at, 'YYYY-MM-DD') as date,
   html_url as link,
   substring(body from 1 for 200) || '...' as content
from
   github_search_issue
where
   $1 ~ 'github_issue'
   and query = 'in:body in:comments org:github ' || $2
   limit $3

Les éléments en bleu sont les noms des colonnes d’une table de base de données—dans ce cas github_search_issue, l’une des tables créées par le plugin GitHub de Steampipe. Le hub Steampipe facilite l’inspection des noms et des descriptions des colonnes du tableau et vous montre des exemples d’utilisation des informations du tableau.

Étant donné que la récupération des données ne nécessite pas d’appeler des API ni de décompresser JSON, vous pouvez vous concentrer sur la syntaxe de recherche d’ordre supérieur, à laquelle il faut beaucoup réfléchir, ainsi que sur le défi intéressant (et amusant !) De mapper les colonnes source à un schéma commun.

Les éléments en rouge sont les noms des colonnes qui s’affichent dans le tableau de bord. Pour ce tableau de bord, nous avons décidé que chaque résultat de recherche correspondra à ces cinq colonnes : taper, la source, Date, lienet contenu. La clause AS de SQL permet à chaque strophe de renommer facilement ses colonnes pour qu’elles correspondent au schéma.

La requête complète

Voici la requête complète qui pilote le tableau de bord. Il y a trois strophes comme celle ci-dessus, chacune écrite comme une CTE (expression de table commune) avec des paramètres correspondant aux variables d’entrée. Et il n’y a presque rien d’autre ! Chaque strophe interroge une table basée sur l’API (slack_search, github_search_issue, googleworkspace_drive_my_file), sélectionne (et peut-être transforme) des colonnes, puis aliase les résultats pour qu’ils correspondent au schéma. Il ne reste plus qu’à UNIONNER les trois CTE, qui agissent comme des tables temporaires, et à ordonner les résultats.

with slack as (
  select
    'slack' as type,
    user_name || ' in #' || (channel ->> 'name')::text as source,
    to_char(timestamp, 'YYYY-MM-DD') as date,
    permalink as link,
    substring(text from 1 for 200) as content
  from
    slack_search
  where
    $1 ~ 'slack'
    and query = 'in:#steampipe after:${local.config.slack_date} ' || $2
  limit $3
),
github_issue as (
  select
    'github_issue' as type,
    repository_full_name || ' ' || title as source,
    to_char(created_at, 'YYYY-MM-DD') as date,
    html_url as link,
    substring(body from 1 for 200) || '...' as content
  from
    github_search_issue
  where
    $1 ~ 'github_issue'
    and query = ' in:body in:comments org:${local.config.github_org} ' || $2
  limit $3
),
gdrive as (
  select
    'gdrive' as type,
    replace(mime_type,'application/vnd.google-apps.','') as source,
    to_char(created_time, 'YYYY-MM-DD') as date,
    'https://docs.google.com/document/d/' || id as link,
    name as content
  from
    googleworkspace_drive_my_file
  where
    $1 ~ 'gdrive'
    and query = 'fullText contains ' || '''' || $2 || ''''
  limit $3
)

select * from slack
union 
select * from github_issue
union 
select * from gdrive

order by
  date desc

Tableaux de bord sous forme de code

De nombreux systèmes de tableau de bord peuvent fonctionner avec cette requête. Vous pouvez, par exemple, connecter Metabase, Tableau ou un autre client Postgres à Steampipe et créer le même type de tableau de bord interactif que celui illustré ici. Vous feriez ce travail dans un environnement low-code où les widgets et les paramètres sont gérés dans une interface utilisateur. Le sous-système de tableau de bord de Steampipe adopte une approche différente informée par ses racines d’infrastructure en tant que code (IaC). Les requêtes sur les API doivent être exprimées dans du code SQL géré, comme tout autre code, dans des référentiels contrôlés par version. Les widgets du tableau de bord qui affichent les résultats de ces requêtes doivent également être exprimés en code, et dans ce cas, le langage est le HCL de Terraform.

Voici la définition HCL du tableau de bord de métarecherche. Il déclare trois types de saisir bloquer: sources (sélection multiple), terme de recherche (texte), et max_per_source (sélection unique, qui est la valeur par défaut). Vous pouvez faire beaucoup plus avec le saisir bloc — notamment, vous pouvez le remplir avec les résultats d’une requête SQL, comme indiqué dans la documentation. Ce n’est pas nécessaire ici, cependant.

La table block utilise la requête définie ci-dessus et définit les paramètres qui lui sont transmis. La envelopper L’argument garantit que les colonnes contenant beaucoup de texte seront lisibles.

dashboard "metasearch" {

  input "sources" {
    title = "sources"
    type = "multiselect"
    width = 2
    option "slack" {} 
    option "github_issue" {}
    option "gdrive" {}
  }  

  input "search_term" {
    type = "text"
    width = 2
    title = "search term"
  }

  input "max_per_source" {
    title = "max per source"
    width = 2
    option "2" {}
    option "5" {}
    option "10" {}   
    option "20" {}
  }  

  table {
    title = "search slack + github + gdrive"
    query = query.metasearch
    args = [
      self.input.sources,
      self.input.search_term,
      self.input.max_per_source
    ]
    column "source" {
      wrap = "all"
    }
    column "link" {
      wrap = "all"
    }
    column "content" {
      wrap = "all"
    }
  }

}

Encore une fois, il n’y a pas grand-chose d’autre à voir ici, et il ne devrait pas y en avoir. La création de tableaux de bord en tant que code ne devrait pas nécessiter beaucoup de code complexe, et ce n’est pas le cas.

Aucune magie requise

Tout comme vous n’avez pas besoin d’être un assistant SQL pour créer de nouvelles sous-requêtes, vous n’avez pas non plus besoin d’être un assistant HCL pour les ajouter au tableau de bord. Souhaitez-vous ajouter des sources ? Il existe des dizaines d’autres plugins parmi lesquels choisir, et d’autres sont ajoutés chaque mois. Ils n’offrent pas tous de recherche, mais beaucoup le font, et il est facile de les trouver avec (bien sûr !) une requête Steampipe.

select
  name
  html_url
from
  github_search_code
where
  query = 'search org:turbot org:francois2metz org:ellisvalentiner org:theapsgroup'
  and name ~ 'table'
  and name ~ 'search'
order by
  name

Dans le référentiel steampipe-samples, nous avons inclus le code du tableau de bord présenté ici, ainsi qu’une strophe de recherche supplémentaire pour Zendesk que nous avons supprimée lorsque notre compte d’essai a expiré. Amusez-vous à étendre ce tableau de bord ! Si une API de recherche dont vous avez besoin n’est pas déjà disponible, rendez-vous dans notre communauté Slack et faites-le nous savoir. Quelqu’un est peut-être déjà en train d’écrire le plugin dont vous avez besoin, ou peut-être aimeriez-vous vous en occuper vous-même. Chaque nouveau plugin permet à quiconque peut travailler avec HCL de base plus SQL de manier les API comme un pro et de résoudre de vrais problèmes.

Copyright © 2022 IDG Communications, Inc.

Leave a Comment