You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
sidekick parses Protobuf or OpenAPI (and whatever comes next) and creates a api.API model of the service specification.
Then we ask the target language Codec (currently for Rust or Go) a bunch of questions and create the model in templatedata.go. And then we use the same mustache templates that the Codec creates to generate the code.
Maybe a cleaner approach would be to pass the api.API model directly to the Codec and let it call the mustache templates. The Codec can create its own enriched1 model of the API if needed.
@dangazineu suggested the good parts of this issue request, the bad ideas came from somebody else (not me, of course).
This was mostly done as part of #667 and #669. We still have the problem that the enriched language types are re-implementations of the api types, which discourages advancing our model. For example, #655 calls for PathInfo to have references to the fields and messages that each path segment requires, but these are useless in the mustache templates, as they don't know the language-specific naming conventions. So any improvements made to PathInfo would have to be replicated for each language implementation.
We could move model.go into the language package, and have each language template contribute their own methods to the api types directly, but that seems like a hack and bound to get out of hand quickly.
I think the solution is probably to invert the control between the language types and the model, so instead of using the model to construct the language types, we pass the language-specific logic to the model structs as adapter interfaces, and use the model types directly in the templates.
and use the model types directly in the templates.
We talked about this with Julie. That is the plan. Maybe with some annotations introduced by each language.
For now, you can change rusttemplate.go to add the annotations in PathInfo that are needed. At least it is easier now that one needs to worry about only one language at a time.
sidekick
parses Protobuf or OpenAPI (and whatever comes next) and creates aapi.API
model of the service specification.Then we ask the target language Codec (currently for Rust or Go) a bunch of questions and create the model in
templatedata.go
. And then we use the same mustache templates that the Codec creates to generate the code.Maybe a cleaner approach would be to pass the
api.API
model directly to the Codec and let it call the mustache templates. The Codec can create its own enriched1 model of the API if needed.@dangazineu suggested the good parts of this issue request, the bad ideas came from somebody else (not me, of course).
Footnotes
I think that is what the cool kids call them. ↩
The text was updated successfully, but these errors were encountered: