You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The upstream openapi-generator builds an entire gem per openapi spec file. This leads to a huge number of gems but there wasn't much choice.
The new/downstream IBM openapi-sdkgen builds an API class per openapi specification which allows for logical grouping of API classes per gem.
As we move towards the newer style of autogenerated gem we should re-evaluate the gem structure.
I see a few possibilities:
Group APIs by high-level API group, e.g.: Platform, Compute, Storage, etc... (some APIs are in multiple groups)
Group by low-level API group, e.g.: Resource Controller has resource_controller/resource_controller_v2 and resource_controller/resource_manager_v2
Have all APIs in one monolithic ibm_cloud gem
Some combination of the first three, e.g. maybe group all platform APIs into one gem, then separate ibm_cloud_vpc / ibm_cloud_power / ibm_cloud_object_storage
The text was updated successfully, but these errors were encountered:
The upstream openapi-generator builds an entire gem per openapi spec file. This leads to a huge number of gems but there wasn't much choice.
The new/downstream IBM openapi-sdkgen builds an API class per openapi specification which allows for logical grouping of API classes per gem.
As we move towards the newer style of autogenerated gem we should re-evaluate the gem structure.
I see a few possibilities:
The text was updated successfully, but these errors were encountered: