ocis
ocis copied to clipboard
owncloud
use more openapitools/openapi-generator artifacts
Description
currently ocis only uses the generated openapitools/openapi-generator request and response structs, the tool provides even more like interfaces, validations and a server.
User Stories
-
As a dev i want to re-use the as many openapi-generator artifacts as possible which prevents possible errors or missing endpoints.
Value
- re-use generated code to speed up dev time (less code has to be written by the dev)
- reduce the possibility of wrong implemented endpoints
Acceptance Criteria
- a working endpoint which uses the generated artifacts
- time and complexity must be reduced
- has to work with the clients
Definition of ready
- [ ] Everybody needs to understand the value written in the user story
- [ ] Acceptance criteria have to be defined
- [ ] All dependencies of the user story need to be identified
- [ ] Feature should be seen from an end user perspective
- [ ] Story has to be estimated
- [ ] Story points need to be less than 20
Definition of done
- Functional requirements
- [ ] Functionality described in the user story works
- [ ] Acceptance criteria are fulfilled
- Quality
- [ ] Code review happened
- [ ] CI is green (that includes new and existing automated tests)
- [ ] Critical code received unit tests by the developer
- Non-functional requirements
- [ ] No sonar cloud issues
- Configuration changes
- [ ] The next branch of the ocis charts is compatible
@tbsbdr, not sure... i expect ive written it not perfect, could need your help to make it shine :)
kind of, reliability for 3rd party devs, if you have some time we can talk about it tomorrow.
@micbar mentioned TypeAPI introduced in this blog post
hacker news also proposes
- https://smithy.io/ but most code generators seem in development
- fern which also seems to have an API-first use case.
All three alternatives are intended for code generation instead of documentation as OpenAPI is.
And I found a comparison of different go server generators for OpenAPI.
