We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
🤔 フロントとバックのAPIスキーマを統合する仕組みがほしいので、一旦考えてみる
フロントとしての気持ち
The text was updated successfully, but these errors were encountered:
@lemonadern スキーマ駆動開発をしたいということではない?
バックとしては、Fastapiを使っているメリットが半減するような感覚になるので、openapiを手で書きたくないかな。だから、バックの機能が完成してから、フロントの開発に移るという開発フローにはなってしまう。 このフローだと、モックを立てる必要はなくなって、本番と同じサーバーをローカルで扱える。
アプリがスキーマに対して整合性を保てているかどうかは、静的解析またはテストで保証するべきでは?
バックはopenapiを定義しているので、それを上手く使ってフロントrepoでテストしてもらえると助かる。バックのレスポンスが変わった時にテストでfailして気づけると嬉しいね。
見当違いなこと言ってたらごめん
Sorry, something went wrong.
@kathmandu777
@Dz0526 とも話したけど、フロントとしてはスキーマ駆動でやりたい
そして、そこはまた相談するとしても、俺は個人的には Barifac と同じフローではやりたくないです
あのフローはフロントの立場としては辛いところが多すぎると思ってる。 Barifacのフロントの面子がどう感じてるかはわからないしあくまで俺個人の意見ではある。 以下は辛いポイント ⬇️
バックとしては、Fastapiを使っているメリットが半減するような感覚になるので、openapiを手で書きたくないかな。
FastAPIのSwaggerUIが便利なのは分かるんだけど、あれは結局バックエンドの内部実装依存でしかないので、フロントとバックの共通言語として扱うには不便すぎると思います。フロントはバックエンドの実装の事情についていくしかなくて身動きとれなくなるのでやりたくないです。フロントの人(俺)は普通に開発がしんどくなってしまう。(このフローだと型周りのあらゆる便利ツールの利用が潰される)
バックの機能が完成してから、フロントの開発に移るという開発フローにはなってしまう。
これに関しても、バックの進捗にフロントが依存してるのは良くないと思ってる。せっかく分業してる意味が薄れると思うので。 バックエンドが爆速で実装されれば良いかというとそういうことでもなくて、フロントもバックもそれぞれで機能の優先順序を決めて実装していくべきで、どちらかに依存した開発は避けられるなら避けたほうがいいと思う。
このフローだと、モックを立てる必要はなくなって、本番と同じサーバーをローカルで扱える。
これはむしろデメリットだと感じてる。最近テストを書くようになって分かったことだけど、フロントはむしろモックがあるからHTTP境界のテストをうまく書けるんだよね。しかもテストのためのモックを作るのって全然大変じゃないです。フロントがほしいのはスキーマ通りにリクエストとレスポンスをやりとりできるサーバでしかなくて、本番と同じサーバが動いててもあまり嬉しくないです。そもそもオーバースペックだし、実装時点でE2Eテストし続けてるようなものになってて筋が悪いと思う。
調べた感じこれはできないことも無いんだけど、このテストが失敗するタイミングってバックエンドの実装が変わった瞬間で、フロントはそれのおかげで手戻りとかが起きるのが目に見えててかなり嫌です。 テストって実装に対してのチェックが行われるべきで、フロントのテストなのに知らないうちに壊れてる可能性があるのはテストとしてかなり厳しい。 2回めになるけど、バックエンドの実装にフロントの開発フローがべったり依存してるのは分業の意味がなくなるので嫌です。
SwaggerUIが便利だとかOpenAPI Schemaを書きたくないというのももちろん分かるし、もしスキーマ駆動になったら環境づくりが大変だとは思うんだけど、俺はどうにかもうちょっとフロントの開発が楽になるフローを採用したいです。
Barifac見てて結構つらいところが多そうに感じたので文面に起こした。実際どんな開発フローを採用するかに関してはまた話し合いさせてほしい。
No branches or pull requests
Overview
🤔 フロントとバックのAPIスキーマを統合する仕組みがほしいので、一旦考えてみる
Background of the improvement
フロントとしての気持ち
Requirements
Considerations
Implementation policy
Test items
Remarks
The text was updated successfully, but these errors were encountered: