Initial golang and typescript SDK and templates

[cleverguy25]

This is a large PR with lots of generated files, so here is a walkthrough. Basically each language SDK has templates, those templates are used to generate a "raw" API, and there is a handcrafted but light wrapper to "cleanup" the result or provide convenience methods.

• ./.vscode/
  • settings to run/debug unit tests in vscode
• ./Makefile
  • add code generation commands
• ./sdk/esc-api.rest
  • vscode REST extension file to play with APIs
• ./sdk/templates
  • downloaded templates using `openapi-generator-cli author template -g -o -./sdk/templates/<generator_output_dest>
  • This is so we have control but also for go and python we need to add yaml support and some files to support a "raw" client
• ./sdk/swagger.yaml
  • handcrafted swagger/openapi spec
• ./sdk/**/.openapi-generator-ignore
  • suppresses generation of superfluous files
• ./sdk/go/api_esc_extensions.go
  • handcrafted wrapper over the raw API client
• ./sdk/go/api_esc_test.go
  • handcrafted E2E tests
• ./sdk/typescript/esc/index.ts
  • handcrafted wrapper over the raw API client
• ./sdk/typescript/test/client.spec.ts
  • hand crafted E2E tests

[pgavlin]

A few questions here:

• How will we keep the SDK up to date?
• Is the generated code deterministic?
• Can we add a target for testing the TS/JS SDK (or is that already covered?)
• Can we add a step to our GH action to invoke the code generator + run tests?

[cleverguy25]

A few questions here:

• How will we keep the SDK up to date?

Code gen does a lot of the heavy lifting, but the wrapper requires manual work. But that really took me a couple hours and once boilerplate there was easier as it went along.

• Is the generated code deterministic?

Because we download the templates it is very deterministic.

• Can we add a target for testing the TS/JS SDK (or is that already covered?)

What do you mean by target? Like code coverage? Right now the code coverage is low (like 33% last I checked) because the code generated models are very detailed but I think the prime scenarios are well covered.

• Can we add a step to our GH action to invoke the code generator + run tests?

We can certainly run tests. I would prefer, at least initially, that we choose when we run the generator as it really only matters when we update the swagger.yaml doc, but even then would want the dev to run it and include it in the PR.

[pgavlin]

A few questions here:

• How will we keep the SDK up to date?

Code gen does a lot of the heavy lifting, but the wrapper requires manual work. But that really took me a couple hours and once boilerplate there was easier as it went along.

👍

• Is the generated code deterministic?

Because we download the templates it is very deterministic.

👍

• Can we add a target for testing the TS/JS SDK (or is that already covered?)

What do you mean by target? Like code coverage? Right now the code coverage is low (like 33% last I checked) because the code generated models are very detailed but I think the prime scenarios are well covered.

A target in the Makefile that we can run (or just include this in the test target).

• Can we add a step to our GH action to invoke the code generator + run tests?

We can certainly run tests. I would prefer, at least initially, that we choose when we run the generator as it really only matters when we update the swagger.yaml doc, but even then would want the dev to run it and include it in the PR.

This is contrary to our historical approach to code generation. In the past we've run codegen with each PR and then checked for a dirty working tree in order to ensure that our generated code is out-of-date. I have a slight preference for this style, as it makes it easier to ensure that the swagger definition doesn't drift from the generated SDK.