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

[Metadata] Document end-to-end for emitters #1083

Closed
nguerrera opened this issue Sep 26, 2022 · 3 comments · Fixed by #1575
Closed

[Metadata] Document end-to-end for emitters #1083

nguerrera opened this issue Sep 26, 2022 · 3 comments · Fixed by #1575
Assignees
Labels
docs Improvements or additions to documentation

Comments

@nguerrera
Copy link
Contributor

There's enough in the REST layer for a different emitter to handle metadata as the openapi emitter does, but it would be nice to have a small walktrhough on that.

@ghost ghost added the Needs Triage label Sep 26, 2022
@markcowl markcowl added this to the [2022] December milestone Sep 27, 2022
@markcowl
Copy link
Contributor

pri: 1
est: 3

@nguerrera
Copy link
Contributor Author

Also document getEffectiveType here.

@nguerrera nguerrera changed the title [Metadata] Document emitter end-to-end for emitters [Metadata] Document end-to-end for emitters Nov 1, 2022
@nguerrera nguerrera self-assigned this Dec 1, 2022
@nguerrera
Copy link
Contributor Author

nguerrera commented Dec 14, 2022

I have written a sample that calls all of the API. I am still working on cleaning it up and writing doc text to go with it. Work in progress is here: https://gist.github.com/nguerrera/36df0c007be7d37e5e67fd769958030e

Also putting down some rough notes I have on things to cover in the doc text.

Key points:

  1. Put properties in models only if they logically belong there. The feature is about allowing logical models + visibility/metadata annotations. It is not about cramming as much as possible into as few types as possible at all cost.

  2. Emitters are not required to generate split types, they can emit unified types and use the information about which properties are present in which cases in other ways. For example, serializing to request/from response differently, making property that only appears sometimes nullable in a single type, etc.

API cheat sheet

  • getRequestVisibility(HttpVerb): Visibility - use this to determine the visibility implied for data in the request parameters or body. (And note also that Visibility.Read is always applied for response data and therefore there is no corresponding response API.)

  • createMetadataInfo(Program) - create this once for each projected program/service version, use it to reason about metadata and visibility implications

  • MetadataInfo.getEffectivePayloadType(Type, Visibility): Type - use this on every type that is referenced. if it is an anonymous model sourced entirely from named properties after metadata is moved elsewhere or invisible properties are removed, it will recover the named model that should be used. This handles op foo(...Thing) but also many other cases.

  • MetaddataInfo.isTransformed(Type, Visibility): boolean - use this to check if a type undergoes any changes in shape. Can allow for simplifications in emit.

  • MetadataInfo.isPayloadProperty(ModelProperty, Visibility): boolean - use this to check if a property is transmitted as an object property (in the payload) and not invisible or metadata sent elsewhere

  • Visibility.Item - Add this when recursing into an array. It puts all metadata into payload. Useful in scenarios like batching API calls. This is missing from the main metadata docs as well.

  • MetadataInfo.isOptional(ModelProperty, Visibility): boolean. Newly added. Makes properties optional in update operations. Not shown in sample yet, not in main metadata docs yet eiher.

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

Successfully merging a pull request may close this issue.

4 participants