Skip to content

Review modularization/service architecture and config for DataModelSupplier #7

@ianfore

Description

@ianfore

See addition of DataModelSupplier implementations in https://github.com/ianfore/data-connect-trino

Raises some questions about how DataModelSuppliers are modularized. Having them as services is a good approach, but should the specific clients be in the main code base? Or should the clients be external? In the latter case a running implementation would likely be told via some config details where to find its DataModelSuppliers.

Also in the examples in https://github.com/ianfore/data-connect-trino one model supplier was not implemented as a web service. That client accessed schema files locally.

The other DataModelSupplier was a hybrid. XML data dictionaries were accessed over http/ftp so in that sense the client was a true client. However, it also took on the responsibility of transforming the XML to the json schema required for Data Connect.

The original implementation, and the additions above were all pragmatic choices adequate for current needs, but we should anticipate how this would scale as more Data Connect implementations are added. These considerations are likely also relevant to the Starter Kit implementation being developed by the GA4GH tech team.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions