https://linen.dev logo
Join Slack
Powered by
<@U01A6TEQXRU> - just a heads up, can you please p...
# dev-frontend
c
@s - just a heads up, can you please ping artem when you’re done working on the “admin” endpoints of the API? he has the UI mostly done for that and can hook it up to the backend when you’re ready. also let us know if you have a rough ETA.
👀 1
s
I’m hoping to have most of these changes in by tomorrow EOD
FYI @Artem Astapenko
for your purposes though Artem, the main changes will be adding the 
sources/create
, and 
sources/update
HTTP endpoints
which are described in this PR currently https://github.com/airbytehq/airbyte/pull/479
a
Cool. Thank you. I tried to call some endpoints today and they were returning 500 errors :)
s
the ones on master right now?
a
Nope. I switched to branch api v0.2.0 as I remember:)
s
ah. That branch is 100% broken right now
you should be able to generate types if that helps you
but right now it will fail the build
a
Oh. Ok. Makes sense why it was returning 500 errors then.
s
@Artem Astapenko does the api in the PR make sense for you though? Think it’ll work for you when building the UI?
a
Everything looks fine except 2 things: In UI we have only 
name
 and 
defaultDockerRepository
when we create source, but backend also expects 
defaultDockerImageVersion
. Did we just forgot to add it on mockups or something else is expected?
and we also have 1 more thing 
...Clicking on it should open the associated github folder IN A NEW TAB
should I build this url my own as currently its not returned from backend.
s
> but backend also expects 
defaultDockerImageVersion
the version will come from the 
Version
column in the mockup here
from the text input from the user
Ah you mean when calling 
/create
.
a
yep 🙂
s
@John (Airbyte) FYI we’ll need to add a version field to this screen. does that sound good with you?
Assuming adding a version field sounds good to John that should answer the question I believe
👍 2
one sec to answer the other question
The URL to use should come from 
get_specification
for the source or destination
there will be a field called 
changelogUrl
that I’ll add to the 
source_specifications/get
response
so for each source there would need to be a separate network call for the spec which will have the URL. Is that reasonable?
a
Yep. Thanks
@s Do you think we will have working API by tomorrow’s morning? I really need it to finish admin stuff 🙂
s
I’ll make sure to have something that you can work against merged by tonight PST
is this the main piece blocking you right now on v0.2.0?
j
I have a call in 5 min but will update the mockup just after
a
mostly yes. I integrated with endpoints from swagger, but would like to test.
there will be a field called changelogUrl  that I'll add to the source_specifications/get response
Looks like we may need web_backend update for it to return all changelogUrl along with sources in admin side. @charles what do you think? I hope we used graphql from the beginning - it would have made a lot of things much easier. At first I thought we won’t need that much web_backend endpoints ….
c
haven’t been following this thread too closely. catching up. will respond in a second.
a
or can we add those link into source instead? Looks a bit strange that we will have all the meta info in source and only 1 field in source_specification
c
yup. sounds like adding a web_backend endpoint is a good approach.
that’s a good point artem. @s if we are collapsing the configuration of StandardSource and Specification into one, should we collapse the endpoints too?
i’m asking since it might be faster than writing another web_backend enpoint. otherwise i woudln’t be proposing a sort of random refactor right now.
but if you don’t think it’ll be faster, say no, and we can just add the web backend endpoint.
s
for the changelog URL I think that’s fine to go on source since it doesn’t change with docker image versions
I prefer to keep source and spec separate because longer term specs will depend on docker image version down the line. which will not be fixed at the source level.
👍 1
a
if its possible to move those 1 field to 
source
it will be awesome!
s
so I’m proposing: 1. put changelogUrl on 
source
actually, is there anything else you need other than #1 above? with something like that, we won’t need to merge spec and source right?
a
Currently we use spec only in form and do not use in table, so its totally perfect for me if they are not combined.
s
great
👍 1
what I will need from you however to put changelogUrl in 
source
is to add yet another field to the mockup image above, which is 
changelogUrl
and that will be sent along the create call
FYI @John (Airbyte) we will need to add 2 fields to the mockup above in the thread: 1. docker image version 2. changelog URL
j
design done 🙂
(thx @s for the help!)
s
Ok Artem, I have good news and bad news… the good news: the new endpoints are available in this PR https://github.com/airbytehq/airbyte/pull/529 the bad news: this PR depends on https://github.com/airbytehq/airbyte/pull/528 which actually removes 
SourceSpecificationId
and 
DestinationSpecificationId
and replaces all their usages with 
SourceId
and 
DestinationId
which means you’ll need to do some more changes on the frontend to accommodate this. I would have done it myself but it’s a little late over here 😅 I hope the changes are easy enough to follow. You should only need to look at 
config.yaml
between the two PRs to see what’s going on
a
Not quite sure what I need to do with that - I can’t just remove those fields
s
what do you mean?
a
so now, to get sourceSpecification I need to first get sourceId, right?
s
yes, so on that front nothing changed
the difference is now wherever we are using 
SourceSpecificationId
on the frontend we’ll just need to use 
SourceID
and same for destination. the backend has been updated to return 
SourceID
where it returned 
SourceSpecificationId
before
a
Not quite sure about the changes right now, as I need to first check what it affects 🙂 probably it won’t be a problem
s
👍 I’m hoping it won’t be an issue — it should be a drop-in replacement of IDs
a
so I will be able to get source_specification based on sourceId, right?
s
yes
a
if its just a replacement of id - then its not a problem. Its possible that I wasn’t using those field a lot on UI 🙂 I will check and let you know if I have any questions, but so far everything looks perfect. Thank you!
s
awesome 🎉
3 Views
Open in Slack
PreviousNext
Powered by