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
Problem Statement
The SDK currently requires users to create specific object types (like EndpointCoreConfigInput, AiGatewayConfig, RateLimit, EndpointTag) when e.g. creating a serving endpoint (sticking to this as endpoint creation/updating and gateway configuration is my current use case). This can be cumbersome and somewhat challenging to learn.
For instance, creating a serving endpoint currently looks something like:
Even for someone experienced with the API, it takes a lot of extra time consulting docs making sure the classes are properly instantiated.
This is made more challenging by how deeply nested these types are (see above).
Proposed Solution
Allow the SDK to accept both custom objects and plain dictionaries for complex type parameters, with a recursive helper function that converts dictionaries to appropriate object types while handling nested structures and type compatibility. For example, the create() method could be updated to accept either custom objects or dictionaries (resulting in the following signature):
Additional Context
One of the use cases this enables is making it much easier to update configs—you can just .update() the corresponding dict. It would also:
Make it more similar in usage to the MLflow deployments SDK (at least for model serving), which does let you pass configs as plain dicts
Make objects you might send via a REST API request with the requests library more compatible with the SDK, without a tricky translation to specific object types.
The text was updated successfully, but these errors were encountered:
Problem Statement
The SDK currently requires users to create specific object types (like EndpointCoreConfigInput, AiGatewayConfig, RateLimit, EndpointTag) when e.g. creating a serving endpoint (sticking to this as endpoint creation/updating and gateway configuration is my current use case). This can be cumbersome and somewhat challenging to learn.
For instance, creating a serving endpoint currently looks something like:
Even for someone experienced with the API, it takes a lot of extra time consulting docs making sure the classes are properly instantiated.
This is made more challenging by how deeply nested these types are (see above).
Proposed Solution
Allow the SDK to accept both custom objects and plain dictionaries for complex type parameters, with a recursive helper function that converts dictionaries to appropriate object types while handling nested structures and type compatibility. For example, the create() method could be updated to accept either custom objects or dictionaries (resulting in the following signature):
Additional Context
One of the use cases this enables is making it much easier to update configs—you can just
.update()
the corresponding dict. It would also:The text was updated successfully, but these errors were encountered: