OpenAPI SDK Generator filtering and structuring support

[uroslates]

While working with the cloud-sdk-js library I've noticed that it lacks the support for filtering out (and that way also implicit possibility of splitting/slicing and customising the structure or organisation of) the generated SDK.

It would be very helpful when the openapi generator (or generator in general) would provide support for filtering out the parts of specification, making the generator generate only the relevant parts of the SDK, based on certain criteria (like for example Tags or event Segments or Namespaces).

• This feature in a way suggests 2 separate features:
  • filtering
  • Organisational changes - Segmentation/Name-spacing (where also possibly the filtering could be applied)

Possible/suggested solution:

• Maybe one of the easiest ways of implementing support for filtering (not necessarily the best way) might be adding an additional step in specification post-parsing phase that would filter out the irrelevant parts of already parsed Specification object and that way narrow down the amount of generated SDK (affecting both generated APIs and Schemas).

  • Here based on provided filter criteria (which should be also exposed to the CLI as a a --filter input parameter) only post-parsing phase would require changes/additional code (filtering parsed OpenAPI object and keeping only relevant pieces). The generation phase could stay as is W/O any modifications.

• More robust and comprehensive solution would tackle the Organisational feature - introducing additional configuration for allowing Segmentation or Namespacing to be reflected in generating separate SDK packages for each criteria, making sure that any overlapping/reused Schemas or APIs are nicely taken care of through the correct imports (in case of internal dependencies).

Impact / Priority

• Filtering to me seems like a very relevant feature (relatively easy to implement/add), allowing a lots of benefits to the SDKs that are consisting of one big Specification file where on the other hand clients are only interested in a subset of the targeted APIs. An example might be Hybris's OCC apis (one big specification containing many combined segments like B2B and B2C or other segments in general that might be too general for specific clients purposes). This way client bundle could be reduced or event better organised (by using different filters to generate different segments of the SDK manually).
• Segmentation/Name-spacing support is a lower priority that requires a bit more work/changes or considering.

Additional notes/ideas
Maybe even more value would be added to the SDK generators if some of its sub-processes (lifecycles) are architected with extensibility/pluggability in mind. Maybe something like providing hooks (in generate configuration object) for different lifecycles (like for example adding a possibility of specifying specification post-parsing hook to the clients where they might manipulate the parsed OpenAPI spec object to meet their needs, or a hook for decorating a spec path traversal or similar).