Conversation

Notices

1. Embed this notice
   obrhoff (obrhoff@chaos.social)'s status on Thursday, 06-Feb-2025 18:11:48 JST obrhoff

   Finally finished migrating to Apple's OpenAPI Codegen, which fixes a lot of issues I had with CreateAPI.

   I'm thinking of moving the OpenAPI Spec to a own repository and generate the API Clients (Golang, Typescript and Swift) with a Github Action on Trigger.

   Is that a good practice?
   #iosdev #backenddev #github #ci

   • Embed this notice
     obrhoff (obrhoff@chaos.social)'s status on Thursday, 06-Feb-2025 19:16:22 JST obrhoff

     in reply to

     • Lucas ✦

     @lucas I would say yes, to keep the repo slim and make it easier to review changes on the spec itself.

     Ideally you could add build check on PRs, if all the dependencies build fine on changes on the other repositories.

   • Embed this notice
     Lucas ✦ (lucas@post.lurk.org)'s status on Thursday, 06-Feb-2025 19:16:24 JST Lucas ✦

     in reply to

     @obrhoff I was actually wondering where the spec would be maintained in such a setup.

     It’s own repo?

   • Embed this notice
     obrhoff (obrhoff@chaos.social)'s status on Thursday, 06-Feb-2025 21:43:39 JST obrhoff

     in reply to

     • Lucas ✦
     • Benedek Kozma

     @Cyberbeni @lucas Actually I disagree. It should be a in a neutral repositories, since I believe frontend developers should be part of designing a API spec based on their requirements.

     In the end both parties agree on the OpenAPI Spec and start implementing it on each side. (enforced through code generation)

   • Embed this notice
     Benedek Kozma (cyberbeni@techhub.social)'s status on Thursday, 06-Feb-2025 21:43:40 JST Benedek Kozma

     in reply to

     • Lucas ✦

     @lucas @obrhoff Next to the backend code that provides the API.

   • Embed this notice
     obrhoff (obrhoff@chaos.social)'s status on Thursday, 06-Feb-2025 23:14:50 JST obrhoff

     in reply to

     • Lucas ✦

     @lucas I don’t think it’s that necessary. If bots automatically generate client/server code based on the spec, you can provide it as a dependency, just like with SwiftPM or NPM.

     Some servers validate requests based on API specs (e.g., enforcing limits or patterns). In those cases, it might make sense to include the spec file as part of the dependency.

   • Embed this notice
     Lucas ✦ (lucas@post.lurk.org)'s status on Thursday, 06-Feb-2025 23:14:51 JST Lucas ✦

     in reply to

     @obrhoff This feels right. I am wondering how dependent repositories get the updated spec?