Shaping the Scope
Once the overarching goal is defined, the first steps become crucial. My aim is to release an initial version as quickly as possible that already delivers real value.
Shifting Priorities
The original priority was on server stubs and payload structs. Thanks to the adaptation of my toolchain, this item can
now be completely crossed off. I’m absolutely not a fan of immediately pulling a collection of libraries into a project
for every problem. However, it’s essential to distinguish when a dependency makes sense. In the case of code generation,
this wasn’t the core of my project, but rather a “necessary evil”—and an extremely extensive one at that. It therefore
feels right to fully rely on ogen here.
The Mock Server as a Unique Selling Point
The mock server will become an integral component for testing. A programmable interface is planned, allowing specific use cases for integration tests to be defined. This enables significantly more precise tests, rather than just delivering generic responses. Also important is clean handling of test sessions, so that parallel requests are possible without interfering with each other.
The Final Piece
The development of the CLI client rounds things off. It’s more of a “finishing touch,” since the other components already enable complete work with the generated API. Nevertheless, this functionality is personally very important to me to complete the package.
This approach keeps the scope manageable and realistic—and provides a clear roadmap to see tangible results quickly.
The differentiation between core competency and “necessary evil” when it comes to dependencies is an important architectural decision. Particularly the session handling in the mock server is an exciting aspect, since stateful mocks in parallel CI environments are often the biggest source of errors. This elevates the tool far beyond a simple static responder.