[Update][Ease of Use] TypeScript Client Update

[atroyn]

TypeScript Client Update

Chroma's first-party TypeScript client is not very idiomatic / nice to use out of the box with TypeScript projects. The documentation also needs and overhaul to make it clearer.

As we ship features into the Local Chroma v.0.6 milestone, we will also want to make sure that we maintain parity with the JS client.

[Complexity] Subtask

• [Low] Clean up the TypeScript client and make it more idiomatic.
• [Med] (Ongoing) Keep the JS client in parity as new features are released for this milestone.

[AlabasterAxe]

Quick update here: I've started to ramp back up on the Javascript client / describe the scope of work. I've started to block out a shape of the client that would be more idiomatic IMO but don't have anything concrete to share yet. Shooting to have a project breakdown by EOD Monday.

[AlabasterAxe]

@atroyn I've fleshed out phase 1 for this work which is the work to make the client more idiomatic: https://docs.google.com/document/d/1DH9Gl5UQeuDr6vyGgoYUw0TkBxITgXIutZSU-ZYdP_E/edit

For the feature parity work, I just have placeholders while I work on understanding the new requirements better. If you're happy to leave that underspecified while I start work on the JS client improvements, I'll get started. Otherwise, I'll spend more time to understand the scope of the work more completely.

Regardless, it would be useful to understand the roadmap on the Python side and for me to see examples of how these features work in Python. I'd appreciate any additional places you can point me to to learn more.

Thanks!

[atroyn]

@AlabasterAxe I think we can get started on the improvements, and discuss runway along the way.
Regarding the python roadmap, the milestone this issue is in (https://github.com/chroma-core/chroma/milestone/1) contains the planned work; I would be happy to provide more color about any of these / jump on a call.

[atroyn]

@AlabasterAxe

Have reviewed the proposed changes.

• Single collection() method: For now let's not deviate from the python API. The reason that get does not supply a default EF is because we do not currently store EFs together with collections. Shortly that's going to change ([Update][Ease of Use] Persistent Embedding Functions #2287) which will considerably simplify all of this. At that point, simplifying down to getOrCreateCollection probably makes sense.

• Flat Client: I think the flat client is a good idea and does seem more JS-ey, let's go ahead with that.

• Include Types Declaration: Definitely want the types declaration so we get the TS badge

• JS Doc Cleanup: Yes please

-Document Object: row-wise and column-wise layouts are something we've gone back and forth on a lot, and we've decided to stick with columns for the time being. We might revise this in a future release; one piece of info which would be useful here is to take a look at how / where Chroma is being integrated in other OSS projects, and if we find they are often doing this transform, we might want to do it for them.

[AlabasterAxe]

Quick update here: I got some time today to update my PR in response to the above feedback. I've got the implementation pretty much down. I've updated all the unit tests to use the new client and now I'm just going through and getting the existing tests to pass. It's been a little slow to fix the tests at first but I figure it'll speed up as I iron out the issues. Shooting for end of week to have a PR ready for review.

[AlabasterAxe]

@atroyn I've got a PR that I think is ready for review and the tests are passing. I think it would be good to check in on what the process for validating and launching this might be.

One question I have is how it works with documentation? Do I need to update the documentation simultaneously with this PR or is it okay to do that after this PR is merged?

[AlabasterAxe]

@atroyn BTW I've updated that PR with the following changes:

• Updated docs to reflect the changes
• Added a migration section. I labeled the section 0.6.0 because I think that's what you in our meeting but let me know what the right thing to do there is
• Changed the function names to use the term Record instead of Document
• Added some guards for the legacy behavior so that old clients will get nice errors (+ tests for the legacy behavior)

I believe the PR should be pretty much ready to go pending feedback from review.

[atroyn]

Thanks @AlabasterAxe - @codetheweb and I will review this week.