[ResponsesAPI] return openai-defined types #1580
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
PR on top of #1576.
I'm starting to think that it makes sense to define Zod schemas for inputs as we need to validate user's inputs. But that for outputs we "only" need static type checking and therefore we could reuse the types defined in https://github.com/openai/openai-node.
Benefits: no need to redefine stuff manually. It's easy to make mistakes (a parameter that shouldn't be nullable, that could be an array, etc.) when translating from the specs to our codebase. If static typing don't complain then we can assume "it's good".
Also less code to maintain.
Drawback: less flexibility. We don't own the stack and things might get updated in the wild. It's less a problem in this context as it's a server and not a client (and therefore we manage the dependency updates).
Overall I do think it's better to import from openai. Since we won't implement everything at first, it's fine to use
Omit<..., "key-that-we-dont-implement">
which explicitly removes a feature (better than implicit non-definition)EDIT: and it's fine to use them for now and if it's ever blocking in the future, then we redefine stuff ourselves.