API Proposal: Generate multiple files

[erictuvesson]

Justification

Our API is going to be quite big and generating it all into one file will make the file very very large. I would like to avoid this, especially since a lot of the large sets will only be used on some specific pages (included admin pages).

Right now I don't commit the generated code to git, which is something that I would like to do in the future to allow us to follow code changes even if we can follow our swagger spec file.

API Proposal

Having a new way to generate code would be ideal in this situation. It would require a lot of changes to support, I can however see a good potential in being able to generate it per with the same ViewData.

let compiler = new Compiler({
  moduleName: "Test",
  className: "Test",
  swagger: swaggerSpec
});

compiler.compile("output_directory");

Something like that would generate a collection of files from the ViewData and resolve the import paths.

Considerations

• Easier to maintain big projects
• Performance improvements for big projects

[mtennoe]

I like the idea, it should make the codegenerator more powerful and customizable, and with the right abstraction level it would keep things fairly clean.

For your specific case though, have you looked into using webpack with tree shaking? With proper tree shaking configured you should end up only bundling the functions that you are actually using per page/component/application/etc. We have great success with that in another project using the code generator, where the resulting code generated file is pretty big. It is also possible to target the input swagger.json file more per page/component/application, but there are ofc. complications there if endpoints of the API is reused across those components

[erictuvesson]

Before getting started with this it would be nice to do a bit of refactor of the current architecture, to allow for better customization from the start.

I haven't looked into Webpack tree shaking, perhaps I should, I do prefer to not do changes to Webpack unless I really have to. I currently have a few Webpack configs running on the same code, so keeping them in sync is not pleasant.

[mtennoe]

Agree, some cleanup is recommended before starting this work (not just for this specific proposal, but for the others as well).

Re. tree shaking: I really recommend looking into it overall, as it allows you to tree-shake away other unused stuff as well (dead code from your own project, unused library code, etc), which can really reduce the size of your shipped bundles