Charles, I was able to have a quick look: So far only few comments on API: 1.

/v1/web_backend/connections/get and /v1/web_backend/connections/list

I need info for destination (the same as for Source)
destinationName
destinationId
destinationImplementationId
connectionConfiguration

2. I need data for Destination column in form like [{name: “”, connectorName: “”}]

@Artem Astapenko could you elaborate on this:

2. I need data for Destination column in form like [{name: “”, connectorName: “”}]

Are you saying that in the

/get

and

/list

endpoints for wb you need these fields?

`could this be achieved by doing a 

/connections/list

` Yes, I suppose those are changes we need.

@Artem Astapenko https://github.com/airbytehq/airbyte/compare/sherif/list-filtered so something like this?

Yeah, something like that we need for second page, when you open specific source. Actually do we need second endpoint? Probably we can already add it to existing one. So idea is next: 1. on the first page, we show the user connections, but groupedBy destinations 2. we click on some source 3. on this page we show connections filtered by sourceId I have just understood, that probably we do not need any backend improvements right now, to support such listing, but the problem is, that it won’t work well for pagination. As I remember we do not have pagination right now. So, we need 4 types of requests in case we want to have pagination in future. /wb/connections/list?groupBy=source /wb/connections/list?groupBy=destination /wb/connections/list?destinationId={destinationId} /wb/connections/list?sourceId={sourceId} Otherwise, I can just get all connections on client and filter them there Do you see what I mean? What do you think?

I see the issue here

right now we do not support pagination and actually it will in need some additional time to support it. So UI just receives all available entities right now

right so if I make these 4 endpoints today, wouldn’t that actually be more work on your side than if we do the client side filtering approach you mention here:

Otherwise, I can just get all connections on client and filter them there

?

yep. Thats what I am trying to say. Probably I can just filter everything right now on frontend and it will be faster. But It may be useful to add such task for future needs.

okay