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

Skip the templatedata.go intermediate step #653

Open
coryan opened this issue Jan 9, 2025 · 2 comments
Open

Skip the templatedata.go intermediate step #653

coryan opened this issue Jan 9, 2025 · 2 comments
Assignees
Labels
sidekick Issues related to the code generator type: cleanup An internal cleanup or hygiene concern.

Comments

@coryan
Copy link
Contributor

coryan commented Jan 9, 2025

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).

Footnotes

  1. I think that is what the cool kids call them.

@coryan coryan added type: cleanup An internal cleanup or hygiene concern. sidekick Issues related to the code generator labels Jan 9, 2025
@dangazineu
Copy link
Collaborator

dangazineu commented Jan 17, 2025

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.

@coryan
Copy link
Contributor Author

coryan commented Jan 17, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
sidekick Issues related to the code generator type: cleanup An internal cleanup or hygiene concern.
Projects
None yet
Development

No branches or pull requests

2 participants