You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
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
What do others think? Or maybe there's other ways of thinking about this problem?
Beta Was this translation helpful? Give feedback.
All reactions