Approaches for consuming 'Electro tables' from other languages

[PeterBaker0]

I am really enjoying the developer experience for ElectroDB within typescript. Nice typing, clear crud operations, useful abstractions over single table concepts while providing sufficient control. However I'd like to discuss ideas for increasing interoperability when accessing ElectroDB designed tables from other programming languages.

I have found that there is a pressure point due to this loss of transparency (to some extent) into how to query the table (without ElectroDB translating).

Example use case - I was working on a project which used DynamoDB to index some documents/urls etc for indexing into a ChatGPT style document QA service. To access this data from Python, I either need to:

a) recreate the queries for specific access patterns manually based on how ElectroDB sets up the pk/sk's, or
b) proxy the access through a typescript API

Both options are a little difficult/non-ideal.

a) scares me because we are managing the mapping from software defined ElectroDB schema into dynamo query in two places now (once in ElectroDB, once in the python code) - migrations, updates, fixes etc become difficult here + no typing to help etc.
b) is more ergonomic but less performant and adds additional complexity (i.e. maybe we need to think about inter-service authentication in a way we didn't need to previously for simple applications)

Do others have ideas on better approaches? This could be thinking short or long term.

I have some ideas

• codegen approach i.e. ElectroDB can operate in a codegen mode where it builds out pre-defined query/op patterns into JSON documents representing boto queries/ops (probably the least work to implement but somewhat risky/thin wrapper over the (a) approach above). Python could then read the JSON as required and execute the query from that.
• client libraries - i.e. ElectroDB is reimplemented to some extent in other languages e.g. Python - to keep a single source of truth for table schemas we might then need to generalise the schema definition into an interoperable format (maybe some DSL for electro schemas, or electro could export an interoperable format which Python or other client libs can read)

What do others think? Or maybe there's other ways of thinking about this problem?