Giters

turbot / steampipe-plugin-sdk

Steampipe Plugin SDK is a simple abstraction layer to write a Steampipe plugin. Plugins automatically work across all engine types including the Steampipe CLI, Postgres FDW, SQLite extension and the export CLI.

Home Page:https://hub.steampipe.io/plugins

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Minimally hosting a plugin

ncruces opened this issue · comments

commented

Motivated by this SQLite forum post, I had a stab at making plugins available to my pure Go SQLite driver.
Here's the current state of it.

Is there a minimal example of hosting a plugin?
Is GRPC really required for an in-process plugin?

I understand that this repo is mostly geared towards developing plugins with the SDK, not hosting them, so if there's a better place to ask this question, any guidance is appreciated.

Thanks!

commented

Polite bump: @judell

commented

Hey I'm really sorry to have missed this until now. I don't think there's an example of minimal hosting. We'd need @kaidaguerre to weigh on the GRPC question. @graza-io might be able to provide a SQLite perspective.

Can you say a bit more about the scenario(s) you envision if ncruces/go-sqlite3#56 did what you have in mind?

commented

Well, I just find SQL a very nice API for the kind of stuff that steampipe does.
And whereas for exploratory stuff a shell is great, I'm sure being able to use it from within Go's database/sql, is useful as well.

Now, obviously, if you're using Go you can always drop down to the AWS Go SDK, but again: (1) SQL is nice, and (2) being able to intelligently join across clouds/services with just SQL (!) bridging the gap really feels like a superpower.

Since plugins are Go, I feel that loading them as independent .sos using steampipe-sqlite through mattn/sqlite3 probably adds a lot of friction when compared to just getting to a (mostly?) cgo-free solution that you can simply go build?

PS: I think I got a bit further by going down GRPC. I haven't invested a lot of effort so far. Was waiting on a little feedback that this is not crazy, and may be worth the time sink.

As I said, I find the concept of using SQL as an unifying API for this kinda stuff very enticing, and tried making the SQLite virtual table (and other extension) APIs in my wrapper/driver particularly developer friendly, so that these kinds of extensions are easy to implement. Having a GRPC plugin API in the middle doesn't necessarily add a lot of value for this use case, but instantly making available 140 (?) plugins certainly does (even if there's a square-peg-round-hole component in there).

commented

really feels like a superpower

Indeed it is!