Skip to content
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

Merged
merged 19 commits into from
Aug 30, 2023
Merged

Conversation

pgautier404
Copy link
Contributor

@pgautier404 pgautier404 commented Aug 11, 2023

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.

@pgautier404 pgautier404 force-pushed the add-vector-index-client branch from 234a141 to 846712f Compare August 14, 2023 20:40
@pgautier404 pgautier404 force-pushed the add-vector-index-client branch from 99756cb to d1eb54b Compare August 23, 2023 23:13
@pgautier404 pgautier404 marked this pull request as ready for review August 24, 2023 18:42
@pgautier404 pgautier404 requested a review from anitarua August 24, 2023 20:48
Copy link
Contributor

@cprice404 cprice404 left a 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/vector-client-props.ts Outdated Show resolved Hide resolved
// 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';
Copy link
Contributor

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 {
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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.

@pgautier404 pgautier404 requested a review from cprice404 August 24, 2023 22:43
cprice404
cprice404 previously approved these changes Aug 24, 2023
Copy link
Contributor

@cprice404 cprice404 left a 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

Copy link
Contributor

@malandis malandis left a 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

packages/core/src/messages/responses/list-indexes.ts Outdated Show resolved Hide resolved
@pgautier404 pgautier404 force-pushed the add-vector-index-client branch from 73e7c99 to 0a9db39 Compare August 25, 2023 17:31
@cprice404
Copy link
Contributor

@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.

@pgautier404 pgautier404 force-pushed the add-vector-index-client branch from a0b7152 to fb4853c Compare August 25, 2023 19:33
@pgautier404
Copy link
Contributor Author

pgautier404 commented Aug 25, 2023

@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.

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 index.ts of each SDK. All clients, configs, responses, loggers, and so on are imported from the root. For example, the imports in examples/nodejs/cache/advanced.ts are:

import {
  CacheGet,
  ListCaches,
  CreateCache,
  CacheSet,
  CacheDelete,
  CacheClient,
  Configurations,
  MomentoLoggerFactory,
  DefaultMomentoLoggerFactory,
  DefaultMomentoLoggerLevel,
  ExperimentalMetricsCsvMiddleware,
  ExperimentalRequestLoggingMiddleware,
  CredentialProvider,
} from '@gomomento/sdk';

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.

@cprice404
Copy link
Contributor

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.
@cprice404
Copy link
Contributor

@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:

#784

I think that's too risky for a 1.x. So my current thinking is:

  • The control plane responses in this PR now have Vector in their names
  • Users who want better namespacing can opt to import vector from the main index, and then reference these as vector.*, but
  • The types are also available from the main index for consistency / simplicity.
  • The data plane response types (coming in the next few PRs) will all be prefixed with Vector*, like the current Cache ones are prefixed with Cache*.

LMK if you are okay with that.

@malandis
Copy link
Contributor

malandis commented Aug 30, 2023

That's fine with me. My only concern was some of the names can get unwieldy/long, eg VectorAddItemBatchResponse, VectorAddItemBatch.Success. If that's actually not bad then works for me.

@cprice404
Copy link
Contributor

That's fine with me. My only concern was some of the names can get unwieldy/long, eg VectorAddItemBatchResponse, VectorAddItemBatch.Success. If that's actually not bad then works for me.

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.

Copy link
Contributor

@malandis malandis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cprice404 cprice404 merged commit f1721cc into main Aug 30, 2023
@cprice404 cprice404 deleted the add-vector-index-client branch August 30, 2023 18:24
cprice404 added a commit to cprice404/client-sdk-javascript that referenced this pull request Aug 31, 2023
* feat: adding preview vector index client

Co-authored-by: Michael Landis <[email protected]>
Co-authored-by: Chris Price <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants