How we built a codegen solution for SDKs to create humanlike code (opens in new tab)

(stytch.com)

17 pointsjelambs2y ago4 comments

4 comments

We recently built our own codegen solution to automatically create, maintain, and document our backend SDKs so that we didn’t have to compromise on either quality or maintenance burden. Also see part one of the series where we discuss how compiler theory inspired our solution: https://stytch.com/blog/what-does-compiler-theory-have-to-do...

verdverm2y ago

Interesting take on code gen. We went the way of declarative -> text/template (Go vs jinja in python), but use CUE as the input. Here, we can do many of the things that you implement in the translations and hybrid method.

We actually used to do something similar, but were able to remove tons of code and move that to the user layer so they can control, because each language has its own patterns and snowflakes. Basically lift the DSLs, transforms, and templates out of the implementation. CUE also provides some really powerful building blocks for schemas, aggregations, and defaults, while also reducing how much we have to write as humans.

https://github.com/hofstadter-io/hof

jelambsOP2y ago

Thanks for sharing! We had a slightly different cost/benefit analysis for our use case with fairly straightforward APIs but know that might not be the same for everyone.

verdverm2y ago

indeed, we are building a code gen framework that is technology agnostic, so we don't want to force writing your code gen processing in a specific language. Text templates make a lot of sense here. One other benefit I see here is that the person writing spec -> code is writing that transformation in the output space, rather than in a language space.

If you already have a different source of truth (like protobufs), then other methods will make more sense. We think CUE is a great language for the source of truth as it has integrations with all the common config formats as well as tech like protobufs and OpenAPI schemas. It's also much nicer to express large amounts of declarative code in.

Anyway, thanks for sharing as well! I found your perspective quite interesting too. I have some desire to see something like JSX for our CUE+templates, but that is still quite unclear and a long-term vision

j / k navigate · click thread line to collapse

4 comments

jelambsOP2y ago

verdverm2y ago

https://github.com/hofstadter-io/hof

jelambsOP2y ago

Thanks for sharing! We had a slightly different cost/benefit analysis for our use case with fairly straightforward APIs but know that might not be the same for everyone.

verdverm2y ago

j / k navigate · click thread line to collapse