Absorb javascript client

[MikeNeilson]

At this time the current javascript client is maintained independantly, this is made it difficult for the JavaScript client to keep up with changes. Additionally it is the client that finds the majority of issues with the OpenAPI Spec Output.

[MikeNeilson]

Current javascript API: https://github.com/HydrologicEngineeringCenter/cwms-data-api-client-javascript/tree/main

[krowvin]

I do wonder if a git tree merge/single repo makes sense. If your preference is to lean towards a more monolithic repository then that is a different conversation.

I think it is possible with the uses reference in a GitHub action

I.e. could we trigger a GitHub action in another repo? I think it is simplified some because both Repos are public. But a token(?) would most likely be required to run:

jobs: 
  build-and-deploy-cda-js: 
    uses: https://github.com/HydrologicEngineeringCenter/cwms-data-api-client-javascript/.github/workflows/build-and-deploy.yml@main 
    secrets: inherit

But there also exists the conversation of being able to prevent a merge if this process fails. The above suggests it does the build and the deploy but you might consider only wanting to be accountable for the build in order for a PR to merge?

Another thought was if these needed to be in the same org but I think the token would work as well.

Summoning @jbkolze for additional thoughts

[MikeNeilson]

don't overthink it. when the time comes (sometime after we've added the openapi validation) we'll just do a squash merge of the latest state of the client into it's own sub project and integrate it all together into the cda build.

[krowvin]

own sub project

But I also didn't know this was a thing (unless you just mean conceptually)

I was mostly fixating on organization

Repo A - Data API
Repo B - Client 1
Repo C - Client 2

But this being the generator; it's mostly generator setup and not someone's custom source.

[jbkolze]

I was originally envisioning something similar to what @krowvin mentioned above -- basically, keeping the repos separate and triggering a build/publish action for cwmsJS upon CDA updates. CDA is such a large project at this point that I'm a little leery of combining more things into it. Personally, I help maintain cwmsJS but not so much CDA so having the two separate makes the DX a little nicer.

All that being said, if it "just works" then I'm not really too worried about how it's managed. Ideally once the build workflow is streamlined it won't need to be fiddled with all that much from that point on.

[MikeNeilson]

It wouldn't be too difficult to setup the permissions to generate a PR. So we can still keep them separate. I can see the value of both.

At a minimum, to support either case, we need to be able to generate an appropriate openapi json/yaml artifact that can be consumed. After that we can create a few experiments and make a more informed decision.

[krowvin]

At a minimum, to support either case, we need to be able to generate an appropriate openapi json/yaml artifact that can be consumed.

I'm looking at bumping CWMSjs to the latest CDA target on the national.

There are issues with the recent endpoint providing values from the objects (probably the spec/generator version) among others (missing endpoints from the generated code/newer releases of prod).

Are we at a place I should try to run the generator with the existing code found:
https://github.com/hydrologicengineeringcenter/cwms-data-api-client-javascript

It would be the simplest for me to get a release out, otherwise I may need a bit of back and forth with you to finalize i.e.

create a few experiments and make a more informed decision

[krowvin]

I'm looking at bumping CWMSjs to the latest CDA target on the national.

Sept release, I have done that here, waiting on a review:
HydrologicEngineeringCenter/cwms-data-api-client-javascript#26

I am going to create a branch from this issue and assign to myself. I will draft PR any work that I do especially if the above PR is still pending from the original repo.

I.e. Consuming client from other repo