Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: Support OpenAPI reflection #79

Open
dilyevsky opened this issue May 27, 2020 · 3 comments
Open

Feature: Support OpenAPI reflection #79

dilyevsky opened this issue May 27, 2020 · 3 comments

Comments

@dilyevsky
Copy link
Contributor

dilyevsky commented May 27, 2020

I'm working on a prototype to have OpenaAPI types reflected in Starlark (e.g use case - #70). Rough API I'm shooting for:

monitoring = openapi("monitoring.coreos.com/v1")

def main(ctx):
    return monitoring.PrometheusRule(
        metadata = ...,
        spec = monitoring.PrometheusRuleSpec(
            ...
        ),
    )

...so it's very similar to proto types but separate registry and reflection is based on OpenAPI v2/3 schema definitions.

I could package this in a separate library but skycfg seems like a logical place for it considering above so opening this to gauge interest, etc

+cc @jmillikin-stripe

@jmillikin-stripe
Copy link
Contributor

This seems like it'd be difficult to reconcile with skycfg's goals of being hermetic and deterministic, since the behavior would now depend on dynamically fetching API specifications.

Maybe it'd be possible to define a mapping from OpenAPI to Protobuf? Then that could be combined with the new dynamic reflection capabilities in go-protobuf master.

@dilyevsky
Copy link
Contributor Author

This seems like it'd be difficult to reconcile with skycfg's goals of being hermetic and deterministic, since the behavior would now depend on dynamically fetching API specifications.

In my prototype I'm letting the library user decide on that by requiring SpecProvider interface which just returns OpenAPI doc by string key. Fwiw you can already do similar non-hermetic type injection with existing proto registry interface 🤷

Maybe it'd be possible to define a mapping from OpenAPI to Protobuf? Then that could be combined with the new dynamic reflection capabilities in go-protobuf master.

Yeah I've thought about adopting similar approach and there are even some libraries one can re-use to do this (at least for v1 google/protobuf api) but it seems like that would be equivalent of just compiling Open API schema into binary as an embedded asset via https://github.com/markbates/pkger or similar).

@dilyevsky
Copy link
Contributor Author

dilyevsky commented May 28, 2020

Then that could be combined with the new dynamic reflection capabilities in go-protobuf master.

So I was looking more deeply into this option and this should work so my next question is what is github.com/golang/protobuf v2 API migration plan? 😄

I'd imagine Skycfg will need to support both v1 and v2 reflection for some time? I can start kicking some tires on that if you haven't already (should probably open separate issue for that).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants