[Groups UI] - Vaults endpoints

[tdraier]

POST /w/[wId]/vaults - create vault

{
  name: "vault name",
  members: [ uids ]
}

GET /w/[wId]/vaults - list vaults

[ 
 {
  name: "vault name"
 }
]

GET /w/[wId]/vaults/[vId] - get vault info (?)

PATCH /w/[wId]/vaults/[vId] -

{
 name: "name"
 members: [ uids ]
 content : [
  { data_source: id , parents: [ ... ] }
 ]
}

GET /w/[wId]/vaults/[vId]/data_sources - get all vault data_source_views:

[
  {
    category: ["managed"|"files"|"webfolder"|"apps"]
    createdAt: ..,
    updatedAt: ..,
    editerByUser: { },
    usage: 10,
    data_source: {
      name: "managed_notion",
      connectorProvider: "notion",
      ...
    },
]

GET /w/[wId]/vaults/[vId]/data_sources?category=["managed"|"files"|"webfolder"|"apps"] filtered by category

GET /w/[wId]/vaults/[vId]/data_sources/categories : GroupedDataSourceViewType[]

[ 
 { category:"connected", count: 10, usage: 10 }, 
 { category:"folder", count: 20, usage: 10 }
]

GET /w/[wId]/vaults/[vId]/data_sources/[dsvId]/content?parentId similar to w/[wId]/data_sources/[name]/managed/permissions can be used for managed/folders/website ? returns a ContentNode[]. Add file size, number of children (is possible)

• members GET /w/[wId]/vaults/[vId]/members - get members list POST /w/[wId]/vaults/[vId]/members - add member

[spolu]

Let's be more explicit I think with /../vaults/../data_sources and /../vaults/../data_source_views

Aggregating different objects under the same endpoints is generally something we live to regret + it's not RESTful?

[flvndvd]

Let's be more explicit I think with /../vaults/../data_sources and /../vaults/../data_source_views

Aggregating different objects under the same endpoints is generally something we live to regret + it's not RESTful?

I'm not sure I understand your concerns about unifying everything behind a single endpoint. The logic for displaying content nodes remains unchanged. The vault path determines the current user's access to the resource. In this case it might makes sense as vaults with also bundles dust apps in the future. Looking more broadly at our needs, I don't think we want to have to call many different endpoints in the assistant builder when a user want to select documents from a data source or a view, do we?

In the app, I've started to implement this approach and created a common interface using duck-typing. This allows us to use the new DataSourceOrView type across various contexts where the behavior isn't affected by whether it's a data source or a view. For example, in the assistant builder and when browsing the tree, there's no difference between selecting a data source or a view. This change will help us transition and ensure the UI isn't cluttered with typeguards in 50+ different places.

Curious to hear your thoughts/FUD you might have about the approach we take here.

[spolu]

My main concern is that it's 100% sure we don't want to do that in the public API so it begs the question for our internal API.

Short term this seems desirable indeed and since this is for internal use this is easy to refactor so I'm not too worried but I still think it's possible we'll want to move away from it at some point... but that's likely a bias towards dead simple API and code constructs vs more abstracted layering.

Here my unexpressed worry is that it's going to be harder for new comers to understand quickly DataSourceOrView and find where the "real code" is. I know we have different sensibilities on that topic.

[spolu]

Basically we want to strike the right tradeoff between the dead simple with lots of diff and the purely abstract with indeed much less diff but so much abstraction that it's harder to find what code is run when 👍

Code simplicity and explicitness is something nearly impossible to recover yet an incredible asset as we scale the team.

Locally I know all abstractions are local optimum. I appreciate this. Really. But stacking them together it's too easy to end up with something very hard to reason about. We've all seen it at many companies and in many codebases.

Just trying to push the team to be extra mindful.

Explicit endpoints are harder to manage but they are so much easier to reason about. Not saying we should do it. Just voicing the trade off to invite everyone to think hard about it 👍

[flvndvd]

Absolutely, I’m totally on the same page regarding the public API! My main point here is about the internal API. We don't necessarily need to mirror the architecture of the public API for internal use. The internal API should first meet our needs and abstract complexity if we can/need.

Basically we want to strike the right tradeoff between the dead simple with lots of diff and the purely abstract with indeed much less diff but so much abstraction that it's harder to find what code is run when 👍

💯 Aligned!