add --schemaURL option to wgc subgraph publish

[kappasims]

Component(s)

No response

Is your feature request related to a problem? Please describe.

For code-first GraphQL implementations, a physical schema file doesn't necessarily exist in the project. Rather, it is more common for a server-generated schema to exist at a specific endpoint. When my schema changes, I currently must download this file manually and copy it to my project, then run the publish command, or script this process.

Describe the solution you'd like

It seems like it would be fairly trivial to provide a command line option for the URL at which a schema resides. This could possibly be implemented by making a curl or similar request to the URL, and then piping the output to a temporary file, at which point you could hook into to the existing publish flow.

Describe alternatives you've considered

Scripting this manual process

Additional context

No response

[github-actions]

WunderGraph commits fully to Open Source and we want to make sure that we can help you as fast as possible.
The roadmap is driven by our customers and we have to prioritize issues that are important to them.
You can influence the priority by becoming a customer. Please contact us here.

[jensneuse]

How would you handle authentication? What if the URL is not reachable from where the wgc command runs? What if introspection is disabled? Would these be cases where this approach simply won't work?

Another thought. When you publish a schema file, it's usually part of a repo and checked into git. With introspection, it's possible that errors occur.

[kappasims]

First, I think it's important that I clarify that instead of proposing creating some kind of real-time link between a schema's URL and Cosmo, I'm asking for the ability to have the publish command do a one-time download and publish. The publish command would download the schema from a URL provided from the command line, store it to a temporary location, and then publish that file to Cosmo, (you could also stream the file from memory). This eliminates the need for me to also maintain a physical file in my project, as long as I do a publish every time I change the schema in code. This makes things way easier for both local development and GitHub Actions, for which I'm currently having to write scripts manually in order to achieve the desired behavior.

Authentication: It would be okay to assume the URL is unauthenticated. (This may be a point of contention; it may be desirable to support certain types of authentication)
Failure scenario: Since this is a one-time DL and publish, if the URL is not returning a 200 or expected status code then it is okay to abort.

Since the schema is defined in the code, the code itself can be rolled back to a specific point in time and deployed or spun up locally, and the schema can be downloaded and published at that time. I am actually specifically trying to avoid a case where a checked-in schema differs from the schema generated by the server. That is the worst kind of error.

[jensneuse]

Thanks for your input. Do you think it would make sense to also add this command for "wgc check", or only publish?

[kappasims]

@jensneuse Yes it does absolutely! Sorry if I overlooked that (and am overlooking any other applicable commands with the --schema option)

[kappasims]

One other item I wanted to clarify because it may come up in discussion: If introspection is disallowed in the production environment, is this feature even useful? The answer is yes, because even without this feature the solution is the same: during production deploy, spin up a docker container with the production code in dev mode with introspection on, grab the schema, and publish it. It's just the number of steps I have to take to get there that makes the difference.