https://linen.dev logo
#dev-frontend
Title
# dev-frontend
a

Artem Astapenko

11/04/2020, 12:29 AM
Charles, I was able to have a quick look: So far only few comments on API: 1.
Copy code
/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: “”}]
s

s

11/05/2020, 1:20 AM
@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?
I don’t understand the request
could this be achieved by doing a
/connections/list
and then filtering as needed if we assume we merge this change: https://github.com/airbytehq/airbyte/pull/822?
a

Artem Astapenko

11/05/2020, 2:34 PM
`could this be achieved by doing a 
/connections/list
` Yes, I suppose those are changes we need.
as for second question:
message has been deleted
we have next slide. So currently we do not return to what destination we list as we had only 1 destination before. So I need a way to receive source: {destinations: []} in some way here. And same for destination: destination: {sources: []}
Probably its necessary to add one more web_backend endpoint for it or add some specific query param, where we specify either return all connections by destination and with some destinationId or we return all connection groupBy source with some sourceId
s

s

11/05/2020, 5:59 PM
a

Artem Astapenko

11/05/2020, 6:10 PM
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?
s

s

11/05/2020, 6:21 PM
I see the issue here
would building in this support for pagination mean more work on your end right now? or would the UI just assume 1 page results for now?
a

Artem Astapenko

11/05/2020, 6:22 PM
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
s

s

11/05/2020, 6:23 PM
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
?
I suppose not necessarily since with the client-side filtering approach the groupby is happening on the UI, but that should be straightforward I think?
a

Artem Astapenko

11/05/2020, 6:25 PM
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.
s

s

11/05/2020, 6:25 PM
okay
let’s go with client-side filtering for now to reduce risk on the upcoming release
👍 1
will create an issue for the frontend to note that we made this tradeoff
https://github.com/airbytehq/airbyte/pull/822 merged this change, so now you should have destination info returned from connection reads
3 Views