Replies: 3 comments
-
This sounds like a good idea to me. Having two repositories makes this a little more complicated regarding synchronization, but for the short term the UI project could just grab the OpenAPI YAML from the server repo |
Beta Was this translation helpful? Give feedback.
-
@ognis1205 can you please comment on this issue so that I can assign to you? |
Beta Was this translation helpful? Give feedback.
-
Thank you for sharing your ideas, folks! There are mainly two ideas:
The first idea is straightforward but has a wide range of impacts, so I plan to implement it with the intention of including only this part in the PR at first. As for the second idea, I will share code snippets here separately, so please feel free to share your opinions. I think this issue is also related to this PR. While some parts of the current OpenAPI specification might lead to a somewhat cumbersome implementation, I believe it is a reasonable implementation considering the future: |
Beta Was this translation helpful? Give feedback.
-
The URL paths, requests, and responses of the backend server to be used are strictly defined by the OpenAPI specification.
I think it is better to automatically generate TypeScript interfaces from OpenAPI and then define the paths as union types and the requests and responses as interfaces synchronized with the OpenAPI specification using utility types.
Additionally, rather than using fetch, if you use third-party libraries like axios and implement some utilities, you can implement everything in a type-safe manner with interfaces synchronized with OpenAPI in a single API.
Beta Was this translation helpful? Give feedback.
All reactions