-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add preview vector index client #710
Conversation
234a141
to
846712f
Compare
99756cb
to
d1eb54b
Compare
examples/web/vector-index/doc-example-files/doc-examples-web-apis.ts
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
overall looking good. exciting that the tests pass. I had one question/nit about the Configuration object, and also would like Michael to weigh in with a quick API review, especially comparing/contrasting the response namespacing pattern that he did in python vs. what we should do here.
packages/client-sdk-web/src/index.ts
Outdated
// VectorClient Response Types | ||
import * as CreateIndex from '@gomomento/sdk-core/dist/src/messages/responses/create-index'; | ||
import * as ListIndexes from '@gomomento/sdk-core/dist/src/messages/responses/list-indexes'; | ||
import * as DeleteIndex from '@gomomento/sdk-core/dist/src/messages/responses/delete-index'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Michael I believe that you decided we wanted to start namespacing these a bit more in python. Do you have thoughts on what we should do here?
transportStrategy: TransportStrategy; | ||
} | ||
|
||
export class VectorConfiguration implements Configuration { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will we need these in nodejs SDK too? or does your PR not wire up node.js SDK yet?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not doing anything on the node side in this PR. This is specifically for Web SDK and console.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do you have a sense of how much extra work it would be? I presumed it would be pretty small, and that we would knock them both out together (in fact I'd kind of prefer that we establish a pattern of always adding stuff to both at the same time and not letting them drift from one another).
not a blocker for this PR but if it seems easy and you have bandwidth maybe you could file a follow-up PR before you split.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
still would really like @malandis to skim this if possible but otherwise I'm +1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good just one inconsistency vs the protos
Co-authored-by: Michael Landis <[email protected]>
73e7c99
to
0a9db39
Compare
@malandis what about the namespacing for the response objects? Do you have thoughts on how we should handle that here for symmetry with what you did in Python? @pgautier404 you might want to look at the python PR to see what they are doing there. I think the goal is to stop dumping all the response classes into one big namespace and instead have a separate namespace for Vector vs Cache etc. |
a0b7152
to
fb4853c
Compare
In the Javascript SDKs, there is basically no namespacing whatsoever of classes we export. Every symbol that is exposed to developers is exposed through the root
I don't really see how we could introduce a namespace for the vector index responses that wasn't inherently confusing to users who are importing every other class from the top level. Not to say there isn't a way to introduce namespaced responses in a UX-friendly way. I am not strong enough with TS to have any bright ideas here though. |
discussed this with Michael; there are a few changes I want to get in here before this gets merged. |
…nto a namespace This commit attempts to put a little more intentional organizational structure in place for the vector response types. This diverges a bit from the way the other response types are organized, but we should be able to move the other response types into a structure like this in the future, while still supporting the old import paths for backward compat. I'm not quite satisfied with this yet because I'd like to have a way to optionally import the types without the `vector.` prefix, so I will follow up with another commit to address that.
In the previous commit I had grouped the vector response types into a `vector` namespace, hoping that there would be an easy way to import the classes directly from within that. However, I couldn't find one, so this commit also exports them at the top level of the index so that users can choose whether they want the `vector.` prefix or not.
@malandis I'm done with this and ready to merge it if you are okay with my changes. I tried a few things for namespacing the vector responses. I was able to separate them a little more cleanly in the file tree, and simplify the export statements in the index files, but I wasn't able to do what I really wanted to do, which was this: I think that's too risky for a
LMK if you are okay with that. |
That's fine with me. My only concern was some of the names can get unwieldy/long, eg |
I don't see a better option at the moment and I'm hoping that with autocomplete those won't be too bad. I don't think they are meaningfully longer than the existing names for the Cache response classes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* feat: adding preview vector index client Co-authored-by: Michael Landis <[email protected]> Co-authored-by: Chris Price <[email protected]>
This commit adds a preview vector index client to the Web SDK. The client currently only implements data plane operations including create, list, and delete index.