Separate the Go client into its own `@netlify/go-sdk` repository

[ehmicky]

It seems to me the Go-related code should be abstracted to its own @netlify/go-sdk repository.

This would make both the Go client and the OpenAPI code easier to work with. This would also:

• separate concerns
• speed up CI

However Go imports might be broken when doing so, so this needs to be done carefully.

[DavidWells]

cc @calavera

Will this effect go imports? (e.g. projects using go client with github.com/netlify/open-api/ references)

[calavera]

Will this effect go imports?

definitely. Removing the code from here would break every project depending on it.

If you want to speed CI, why don't you create two parallel jobs? Caching Go's dependencies could also help reducing that time, as well as using a packages proxy: https://proxy.golang.org/

[ehmicky]

I'm closing this issue considering it's too much of a breaking change.

Just for some background, the issue for me was more of a separation concern. The Go client is one of many clients consuming the OpenAPI definitions and it has different requirements and programming languages, so I though it should belong to different repositories.

[ehmicky]

What about separating the OpenAPI code to a new repository, and import it in the current one (as opposed to the other way around)? This would ensure the Go imports are not broken.

Another concern for me is that (not knowing Go) when changing something in Node.js, I am wondering whether I am accidentally breaking the Go client. I actually just did that by moving the swagger.yml file to a src/ folder until I realize the Makefile used to generate the Go client depends on that location. If the Go client was separate and importing the OpenAPI definition, I would be more confident about not breaking it by accident.

The same concern is the reason I am currently not adding CI tests for the Node.js code to the .travis.yml. It's currently used by the Go client and I don't want to break things.

[mraerino]

I also don't see a clear migration path for the go sdk.
This monorepo style also ensures that the SDKs are rebuilt on every openapi change.

We have a CI for detecting basic config errors like moving the swagger file (which might also be a really big breaking change for some people depending on it).
There is a lot of room for improving the test suite of the swagger file and go sdk and I hope we can do that sometime™️.

[mraerino]

I can help you with with improving the CI experience without breaking the go stuff if you want.

[ehmicky]

@mraerino thanks for those extra information! With that in mind, I understand separating is complicated.

Quick question: is there a way for the Go client not to have to rebuilt when the OpenAPI definition changes? For example the Node.js client imports the npm package @netlify/open-api, which will automatically updates on npm install for patch and minor versions.

[mraerino]

is there a way for the Go client not to have to rebuilt when the OpenAPI definition changes?

The Go dependency system works by fetching code from a git repository.
Therefore github is our "package store" in this case. Generation changes will have to be commited. We could do this through a bot.

[ehmicky]

We could also create a npm script command that runs the Makefile? We are already using npm scripts to semi-automate generating the documetnation website when swagger.yml changes.