3 ms·
I was very excited about this project when I first encountered it as it seemed to be the best centralized community-driven way to generate code for multiple lan
by puika 4y ago
I was very excited about this project when I first encountered it as it seemed to be the best centralized community-driven way to generate code for multiple languages and supporting v3.
The more time I spent with it the more disappointed I became. The reason why you are forced to write Java and write your own generator alongside the rest of the project is unclear to me. Extending the mustache templates is a pain (and handlebars experimental). Every little change you want to make requires you to change the library itself. Most generators I looked at (TS clients, Go clients and servers, Python clients) generated dubious code and project structures for actual usage.
My current approach to deal with all of this e.g. in Go server generation is to output to some temp directory and have (long) post generation scripts parse the current and generated AST to (1) restructure to my liking, (2) merge changes where appropriate (the generator would overwrite your code otherwise) and (3) generate helper files with Go templates, which are actually pleasant to use. (2) is necessary if you don't want to have generated maps all over the place to access the handler for this route, the middleware for this other one, etc. You won't have to edit generated files, but good luck figuring out what's going on. As long as you clearly state what methods can be edited and which ones are always replaced with the generator output you should be fine with (2).
You may be thinking:
> why do all of this instead of writing your own generator?
to which I answer: Touché.
- CodeWriter23 4y agoIsn't this the case with all Open Source, that if one really wants to extend something, one must first get into the same mindset as the original designer and understand "their way" of doing it?
- rattray 4y agoFellow "wrote my own generator" person here (I built the codegen system Stripe uses to generate their API client libraries). Sounds like you've got a pretty neat system too, hadn't thought of some of these approaches. We had a similar story – after looking at the OpenAPI Generator and other options, we ended up making our own in JS from the ground up, more or less (it used the internals of prettier to generate pretty code, especially example snippets for docs, across languages). I'm now starting a company (https://stainlessapi.com https://stainlessapi.com, mentioned by OP elsewhere on this thread) to solve this problem more generally. If you ever get tired of maintaining this system (which may not happen, it does sound fun/interesting) or want broader language support, and are open to a commercial solution, drop me a line: alex at stainlessapi.com (open invite of course – and also always happy to just chat codegen things, it's a neat little niche)
- twitchard 4y agoShameless plug for my conference talk on why I prefer a "compiler" approach vs a "template" approach to API library generation https://www.youtube.com/watch?v=mgRreyw-Nlg https://www.youtube.com/watch?v=mgRreyw-Nlg Based on experiences with the same generator at Stripe that Alex (founder of stainlessapi.com) built.
- nevermindiguess 4y agoThey are 8 months old and have “strong revenues”. How do you do that? Seems like magic. I wish I were so talented.