-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New connector_builder
module for handling requests from the Connector Builder
#23888
New connector_builder
module for handling requests from the Connector Builder
#23888
Conversation
airbyte-cdk/python/connector_builder/connector_builder_source.py
Outdated
Show resolved
Hide resolved
airbyte-cdk/python/connector_builder/connector_builder_source.py
Outdated
Show resolved
Hide resolved
… Builder. Also implements `resolve_manifest` handler
13faa1e
to
0dccb4e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! I like the clear and concise documentation that comes with the added valud
airbyte-cdk/python/connector_builder/connector_builder_handler.py
Outdated
Show resolved
Hide resolved
airbyte-cdk/python/connector_builder/connector_builder_handler.py
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
small nits but looks good otherwise
airbyte-cdk/python/connector_builder/connector_builder_handler.py
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question about the return types on the handler, but lgtm!
raise NotImplementedError | ||
|
||
|
||
def resolve_manifest(source) -> Union[AirbyteMessage, AirbyteRecordMessage]: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It feels a little inconsistent that we return either an AirbyteMessage or an AirbyteRecordMessage. The "parent" AirbyteMessage object has fields for each of the relevant message unless the protocol has changed. Shouldn't we be returning an AirbyteMessage w/ the record
or trace
field set and the relevant type
? Or returning a Union[AirbyteRecordMessage, AirbyteTraceMessage]
?
Link to protocol: https://github.com/airbytehq/airbyte-protocol/blob/main/protocol-models/src/main/resources/airbyte_protocol/airbyte_protocol.yaml#L43-L51
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for pointing that out, I think always returning AirbyteMessage
makes sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(updated)
def preparse(args: List[str]) -> Tuple[str, str]: | ||
parser = argparse.ArgumentParser() | ||
parser.add_argument("command", type=str, help="Airbyte Protocol command") | ||
parser.add_argument("--config", type=str, required=True, help="path to the json configuration file") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this must accept a --catalog
parameter to respect the airbyte protocol
def handle_request(args: List[str]): | ||
config = get_config_from_args(args) | ||
source = create_source(config) | ||
if "__command" in config: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We had our internal tech spec explaining why we use __command
to pass commands from the platform to the CDK. Should we make part of it public/documented here in order to provide context to a dev reading this code so that it makes sense for him?
c8aee98
to
aea625e
Compare
return config | ||
|
||
|
||
def preparse(args: List[str]) -> Tuple[str, str]: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the interface should be the same as other connectors so this should also accept --catalog
and and optional --state
It might make sense to always use AirbyteEntrypoint.parse_args
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@clnoll is there a reason to use a preparse method instead of directly calling AirbyteEntrypoint.parse_args
? Using the same method ensures we're using the same interface
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good call, updated to use AirbyteEntrypoint.parse_args
.
@@ -7,6 +7,8 @@ This entrypoint is used for connectors created by the connector builder. These c | |||
|
|||
The spec operation is not supported because the config is not known when running a spec. | |||
|
|||
This entrypoint is also the entrypoint for requests from the [Connector Builder](https://docs.airbyte.com/connector-development/config-based/connector-builder-ui/) Server. In addition to the `__injected_declarative_manifest`, the [Connector Builder backend](https://github.com/airbytehq/airbyte/blob/master/airbyte-cdk/python/connector_builder/README.md) config requires the `__command` key, whose value is one of the commands handled by the ConnectorBuilderHandler (`stream_read`, `list_streams`, or `resolve_manifest`). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it would make sense to provide complete config examples (maybe without the manifest) to clarify how this is meant to be used
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added to the connector_builder
README.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question about using preparse
vs AirbyteEntrypoint.parse_args
but looks good otherwise
…or Builder (airbytehq#23888) Also implements `resolve_manifest` handler
…or Builder (#23888) Also implements `resolve_manifest` handler
…or Builder (#23888) Also implements `resolve_manifest` handler
What
Initial implementation of Connector Builder handlers in the CDK.
This PR just implements
resolve_manifest
handler, but provides the structure we'll use for implementinglist_streams
andstream_read
.How
Modifies the
source_declarative_manifest
to handle Connector Builder requests. These are identified by the presence of a__command
key in the config.If a
__command
key is not present in the config, we create theManifestDeclarativeSource
and then calllaunch
on the source as usual.Otherwise, we instantiate a
ConnectorBuilderSource
to handle the command. TheConnectorBuilderSource
is instantiated with aManifestDeclarativeSource
. To handle theresolve_manifest
request, theConnectorBuilderSource
callsresolved_manifest
on the injectedManifestDeclarativeSource
, and returns the result as an AirbyteRecordMessage whose structure matches the Connector Builder server’s ResolveManifest object.