آیا از جستجوی جداگانه Slack، GitHub و Google Drive خسته شده اید؟ همه این کارها را به یکباره در SQL انجام دهید

هنگامی که APIها به صورت خودکار جداول پایگاه داده هستند، ترکیب نتایج جستجو از APIهای مختلف آسان است.

مشکل را می دانید: کلماتی که به دنبال آن هستید ممکن است در Slack، یا GitHub، یا Google Drive، یا Google Sheets، یا Zendesk، یا … باشد. جستجو در این سیلوها یک ناامیدی رایج است. باید بدون اصطکاک باشد، و این داشبورد Steampipe باعث شده است.

این اولین بازی من نبود. من این سفر را در شروع کردم ۱۹۹۶ و به صورت دوره ای این ایده را بازبینی کرده اند. در ۲۰۱۸ در مورد نسخه ای نوشتم که نمونه کلاسیک ساده‌ترین چیزی بود که می‌توانست کار کند: یک صفحه وب که نشانی‌های اینترنتی جستجو را جمع می‌کند. برای خدمات و بازدیدهای مختلف هر کدام در برگه خود. هر چقدر هم که احمقانه به نظر می رسد، به اندازه کافی مفید بود که کمی مورد استفاده قرار بگیرم، و نه فقط توسط من.

البته من می‌خواستم از APIهای زیربنایی استفاده کنم، نتایج را عادی کنم و آنها را در یک نمای مشترک ادغام کنم. اما تلاش لازم برای به چالش کشیدن همه APIها باعث شد که پروژه بیش از ارزش آن مشکل ایجاد کند. اگر قبلاً چنین کاری را انجام داده اید، می دانید که اکثر سرویس ها APIهای جستجو را همراه با آداپتورهای زبان برنامه نویسی دلخواه شما ارائه می دهند. اما هر سرویس روش خاص خود را برای فراخوانی API، صفحه بندی نتایج و قالب بندی آنها خواهد داشت. این تفاوت‌ها اصطکاک‌هایی را ایجاد می‌کنند که باید بر آنها غلبه کنید تا بتوانید با نتایج به شیوه‌ای ثابت کار کنید.

وقتی بحث API بدون اصطکاک می شود، بسیاری از چیزها ممکن می شود. متاجستجوی موثر یکی از آنهاست. Steampipe شما را از کسب و کار فراخوانی APIها، صفحه بندی نتایج و باز کردن بسته بندی اشیاء JSON خارج می کند. API ها را برای شما فراخوانی می کند و نتایج را در جداول پایگاه داده پخش می کند تا بتوانید کاملاً روی کار با داده ها تمرکز کنید. این بزرگترین مشکلی را که هنگام ساخت داشبورد متاجستجو با آن مواجه می‌شوید حل می‌کند.

همگرایی در طرحواره

چالش بعدی پیوند دادن نتایج جستجو به یک طرحواره رایج است. SQL یک محیط عالی برای انجام این کار است. درخواستی که داشبورد نشان داده شده در اسکرین‌کست را هدایت می‌کند شامل سه مصراع است که برای نوشتن آن‌ها لازم نیست جادوگر SQL باشید. همه آنها از الگوی مشابهی برای جستجوی مشکلات 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
   $۱ ~ 'github_issue'
   and query = 'in:body in:comments org:github ' || $2
   limit $3

موارد آبی نام ستون‌ها در جدول پایگاه داده هستند—در این مورد github_search_issue، یکی از جداول ساخته شده توسط افزونه GitHub. مرکز Steampipe بازرسی نام‌ها و توضیحات را آسان می‌کند. ستون‌های جدول را نشان می‌دهد و نمونه‌هایی از نحوه استفاده از اطلاعات موجود در جدول.

چون واکشی داده‌ها به نیاز ندارد با فراخوانی API و باز کردن بسته‌بندی JSON، می‌توانید روی سینتکس جستجوی مرتبه بالاتر، که در کنار چالش جالب (و سرگرم کننده!) نگاشت ستون های منبع به یک طرحواره رایج، جای تامل زیادی دارد.< /p>

موارد قرمز رنگ نام ستون هایی هستند که در داشبورد نشان داده می شوند. برای این داشبورد تصمیم گرفته‌ایم هر نتیجه جستجو به این پنج ستون نگاشت شود: نوع، منبع، تاریخ، پیوند em> و محتوا. بند AS SQL تغییر نام ستون های خود را برای مطابقت با طرحواره برای هر بند آسان می کند.

پرسمان کامل

این پرسش کاملی است که داشبورد را هدایت می‌کند. سه مصراع مانند متن بالا وجود دارد که هر کدام به عنوان یک CTE (عبارت جدول مشترک) با پارامترهای مربوط به متغیرهای ورودی نوشته شده است. و تقریبا هیچ چیز دیگری وجود ندارد! هر بند یک جدول مبتنی بر API را درخواست می‌کند (slack_search، github_search_issue، googleworkspace_drive_my_file)، ستون‌ها را انتخاب می‌کند (و شاید تبدیل می‌کند)، سپس نتایج را برای مطابقت با این طرح نام مستعار می‌کند. تنها چیزی که باقی می ماند این است که سه CTE را که مانند جداول موقت عمل می کنند، متحد کنید و نتایج را مرتب کنید.

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
    $۱ ~ '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
    $۱ ~ '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
    $۱ ~ 'gdrive'
    and query = 'fullText contains ' || '''' || $2 || ''''
  limit $3
)

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

order by
  date desc

داشبوردها به عنوان کد

بسیاری از سیستم های داشبورد می توانند با این پرس و جو کار کنند. برای مثال می‌توانید Metabase یا Tableau یا یکی دیگر از مشتریان Postgres را به Steampipe متصل کنید و همان نوع داشبورد تعاملی را که در اینجا نشان داده شده است بسازید. شما این کار را در محیطی با کد پایین انجام می دهید که در آن ویجت ها و تنظیمات در یک رابط کاربری مدیریت می شوند. زیر سیستم داشبورد Steampipe رویکرد متفاوتی را بر اساس ریشه‌های زیرساخت به‌عنوان کد (IaC) اتخاذ می‌کند. . پرس و جوها علیه APIها باید در کد SQL بیان شوند که مانند سایر کدها در مخازن تحت کنترل نسخه مدیریت می شوند. ویجت‌های داشبورد که نتایج آن جستارها را نمایش می‌دهند نیز باید به صورت کد بیان شوند، و در این مورد، زبان Terraform HCL< است. /a>.

در اینجا تعریف HCL از داشبورد متاجستجو آمده است. سه نوع بلوک ورودی را اعلام می‌کند: منابع (چند انتخابی)، search_term (متن)، و max_per_source (تک انتخاب که پیش فرض است). با بلوک input می‌توانید کارهای بیشتری انجام دهید—به ویژه، می‌توانید آن را با نتایج جستجوی SQL پر کنید، همانطور که در مستندات. اگرچه در اینجا به آن نیازی نیست.

بلوک table از کوئری تعریف شده در بالا استفاده می کند و پارامترهای ارسال شده به آن را تعریف می کند. آرگومان wrap تضمین می‌کند که ستون‌هایی با متن زیاد قابل خواندن هستند.

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"
    }
  }

}

باز هم چیزهای زیادی برای دیدن در اینجا وجود ندارد و نباید وجود داشته باشد. ساخت داشبورد به عنوان کد نباید به تعداد زیادی کد پیچیده نیاز داشته باشد، و اینطور نیست.

بدون نیاز به جادوگری

همانطور که برای ایجاد پرس و جوهای فرعی جدید نیازی به جادوگر SQL ندارید، برای افزودن آنها به داشبورد نیز نیازی نیست که یک جادوگر HCL باشید. آیا می خواهید منابعی را اضافه کنید؟ ده ها افزونه دیگر برای انتخاب وجود دارد که هر ماه تعداد بیشتری اضافه می شود. همه آنها جستجو را ارائه نمی دهند، اما بسیاری از آنها این کار را می کنند، و یافتن آنها با (البته!) جستجوی 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

در مخزن steampipe-samples که قرار داده ایم کد داشبورد نشان داده شده در اینجا، به همراه یک بند جستجوی اضافی برای Zendesk که وقتی حساب آزمایشی ما منقضی شد حذف کردیم. از گسترش این داشبورد لذت ببرید! اگر API جستجوی مورد نیاز شما در حال حاضر در دسترس نیست، به انجمن Slack ما مراجعه کنید و به ما اطلاع دهید. ممکن است شخصی در حال حاضر افزونه مورد نیاز شما را بنویسد — یا شاید شما بخواهید با آن مقابله کنید خودت هر افزونه جدید این امکان را برای هر کسی که می‌تواند با HCL و SQL پایه کار کند، از APIها مانند یک حرفه‌ای استفاده کرده و مشکلات واقعی را حل کند.