ease of collaborative work: file per schemas, client, server methods

[chaporgin]

Hello and thank you for your great library.

Description

We commit the generated code into the repository. We work on some specifications resolving 5 features simultaneously. 2 developers rarely work on the same endpoint. Considering that, 4 pull requests with specification changes are often subject to rebase after one lucky person commits to the main branch. Thinking of how to improve the workflow I thought that the rebases would be less needed if the generated code were split more. Currently, we have the following files (among the others):

• oas_schemas_gen.go
• oas_client_gen.go
• oas_handlers_gen.go
• oas_request_decoders_gen.go
• oas_request_encoders_gen.go
• oas_response_decoders_gen.go
• oas_response_encoders_gen.go

I believe they are the only source of frequent conflicts, unless when 2 new endpoints are being added, in that case oas_router_gen.go adds to the list above, but I believe this case should be out of scope.

My suggestion is to generate more files, so that:

• each server endpoint handler has it's own file
• each client endpoint handler has it's own file
• each schema has its file.

Downsides:

• looks ugly. Question of taste, I'd say, I don't care much if generated files are named something-something_1_gen.go, something-something_2_gen.go if they serve better to the developer productivity.
• slightly increased compilation times. I believe it isn't very important.

[pmchung]

FWIW, I have a slightly different workflow by having separate yaml per service. There is an opportunity for schema reuse by enabling remote ref but only at the yaml level. The outcome of this is having separate oas packages per service. Not a big deal in terms of the number of file generated and totally avoids the issue of conflicts. The downside is that it's not possible to create generic response for such schemas like Error as there will be one scoped to each package. The workaround I have is to additionally generate a "shared" oas package, disable convenient error, and use my own error handler to return the Error manually. Another source of redundancy are the value helpers (OptString, etc).