Closed diego-aquino closed 7 months ago
Currently, I'm considering the "Alternative 3" as the most promising and our natural first step.
The "Extra: OpenAPI auto-generation" could be a future feature or (most likely) delegated to third-party packages specialized in OpenAPI auto-generation, depending on the programming language and framework of the mocked service. In other words, Zimic would support type schema generation from OpenAPI specification, but generating the maintainers of the mocked service would be responsible for creating, providing and keeping the specification up-to-date.
Definitions
Initial ideas
Alternative 1: Types inferred from source code
Assessment: promising, not feasible directly.
A utility package could be installed in a mocked service, allowing automatic schema type generation by a CLI. The generated types are exported to an intermediate package that must be imported by client apps.
Workflow:
Pros:
Cons:
Alternative 2: Types inferred from real requests
Assessment: not promising, requires manual intervention and is error prone.
A utility package could be installed in client apps, allowing automatic schema type generation by inferring the types from real requests.
Workflow:
Pros:
Cons:
Alternative 3: Types derived from endpoint specification
Assessment: most promising, will be implemented into Zimic.
Having access to the mocked service endpoint specification, Zimic could automatically generate the type schemas. The endpoint specification could follow the standard OpenAPI.
Workflow:
Pros:
Cons:
Extra: OpenAPI auto-generation
There could be ways to infer the OpenAPI specification from the source code of the mocked service. By doing this, alternatives 1 and 3 are combined:
See: