Are there any particular taps that the SDK team are using to drive the ambidextrous case?

Just Athena at this point. But other top candidates are parquet and Snowflake.

Oh ok so the db type taps/targets are the main fit here?

@visch - You’ve thought a lot about loading to SaaS targets in #C01RKUVUG4S - do you think an “ambidextrous” tap/target combo for Salesforce would be interesting? I think, for me at least, the distinction of being ambidextrous implies (1) after loading, you can immediately scan the target schema and produce another catalog file, (2) no unique config is needed to extract data beyond what it took to land it in the first place.

The ambidextrous route seems nice. Only negative I could see is discoverability for people as the repo name would have to be something like taptarget-powerschool or singer-powerschool .

Agreed. This is mitigated by the hub somewhat, but its still something we need to think on if/when ambidextrous-ness becomes a theme 🙂

Ultimately you need some place to share modules between the two, whether that's importing from the other file, a shared modules library, or all in one place is kinda use case dependent. One library does seem the nicest and easiest to test

Yeah, there’s a lot to think through. And not a compelling case from a users’ perspective to prefer an ambidextrous tap if they only want to extract data. I think this really shines on the target side, expecially with SQL-type datasets - and specifically because with SQL-type sources, there just aren’t very different/distinct code paths between reading and writing. As long as we have a

execute_sql()

method specific to the target, in theory the same could be used to extract data. For a while I was very excited about this as an “automatic” feature for SDK-based targets, but on thinking more, there’s generally too much additional code needed for most real-world extract use cases. Even with SQL-type sources, this does eventually break down as soon as we start talking about bulk load and bulk extract - then we need the developer to write custom methods for both the sink and stream capabilities..

The tragic case of Magic vs Readability 🙂 hard judgement calls to make. SDK helps significantly

so here’s a one thought: ambidexterity could potentially manifest as one package (the primary) being a dependency of other (the secondary). This could make sense for SaaS interfaces where the tap is likely the primary use case and the target use case is secondary and likely dependent on the particular implementation of its sibling tap.