Skip to content
New issue

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スキーマを統合する仕組みがほしい #14

Open
lemonadern opened this issue Jun 29, 2022 · 2 comments
Labels

Comments

@lemonadern
Copy link
Contributor

lemonadern commented Jun 29, 2022

Overview

🤔 フロントとバックのAPIスキーマを統合する仕組みがほしいので、一旦考えてみる

Background of the improvement

フロントとしての気持ち

  • REST でやるなら、レスポンスに追従して型書いたりするのって面倒
  • アプリがスキーマに対して整合性を保てているかどうかは、静的解析またはテストで保証するべきでは?
  • スキーマが決まっていると、モックを勝手に立てて開発できるので楽
    • これができると、テストもほぼ自動にできる

Requirements

Considerations

Implementation policy

Test items

Remarks

@lemonadern lemonadern added type:feature Feature Request 1.priority:高 task:backend task:frontend frontend task type:consideration things to consider type:enhancement enhance or request and removed type:feature Feature Request 1.priority:高 type:enhancement enhance or request labels Jun 29, 2022
@lemonadern lemonadern changed the title フロントとバックのAPIスキーマを統合する仕組みがほしい 🤔 フロントとバックのAPIスキーマを統合する仕組みがほしい Jun 29, 2022
@kathmandu777
Copy link
Member

@lemonadern
スキーマ駆動開発をしたいということではない?

バックとしては、Fastapiを使っているメリットが半減するような感覚になるので、openapiを手で書きたくないかな。だから、バックの機能が完成してから、フロントの開発に移るという開発フローにはなってしまう。
このフローだと、モックを立てる必要はなくなって、本番と同じサーバーをローカルで扱える。

アプリがスキーマに対して整合性を保てているかどうかは、静的解析またはテストで保証するべきでは?

バックはopenapiを定義しているので、それを上手く使ってフロントrepoでテストしてもらえると助かる。バックのレスポンスが変わった時にテストでfailして気づけると嬉しいね。

見当違いなこと言ってたらごめん

@lemonadern
Copy link
Contributor Author

@kathmandu777

  • @Dz0526 とも話したけど、フロントとしてはスキーマ駆動でやりたい

  • そして、そこはまた相談するとしても、俺は個人的には Barifac と同じフローではやりたくないです

あのフローはフロントの立場としては辛いところが多すぎると思ってる。
Barifacのフロントの面子がどう感じてるかはわからないしあくまで俺個人の意見ではある。
以下は辛いポイント ⬇️

FastAPIのSwaggerUIらへんについて

バックとしては、Fastapiを使っているメリットが半減するような感覚になるので、openapiを手で書きたくないかな。

FastAPIのSwaggerUIが便利なのは分かるんだけど、あれは結局バックエンドの内部実装依存でしかないので、フロントとバックの共通言語として扱うには不便すぎると思います。フロントはバックエンドの実装の事情についていくしかなくて身動きとれなくなるのでやりたくないです。フロントの人(俺)は普通に開発がしんどくなってしまう。(このフローだと型周りのあらゆる便利ツールの利用が潰される)

開発フローの依存について

バックの機能が完成してから、フロントの開発に移るという開発フローにはなってしまう。

これに関しても、バックの進捗にフロントが依存してるのは良くないと思ってる。せっかく分業してる意味が薄れると思うので。
バックエンドが爆速で実装されれば良いかというとそういうことでもなくて、フロントもバックもそれぞれで機能の優先順序を決めて実装していくべきで、どちらかに依存した開発は避けられるなら避けたほうがいいと思う。

モックサーバと開発サーバについて

このフローだと、モックを立てる必要はなくなって、本番と同じサーバーをローカルで扱える。

これはむしろデメリットだと感じてる。最近テストを書くようになって分かったことだけど、フロントはむしろモックがあるからHTTP境界のテストをうまく書けるんだよね。しかもテストのためのモックを作るのって全然大変じゃないです。フロントがほしいのはスキーマ通りにリクエストとレスポンスをやりとりできるサーバでしかなくて、本番と同じサーバが動いててもあまり嬉しくないです。そもそもオーバースペックだし、実装時点でE2Eテストし続けてるようなものになってて筋が悪いと思う。

スキーマとフロント実装に対するテストについて

バックはopenapiを定義しているので、それを上手く使ってフロントrepoでテストしてもらえると助かる。バックのレスポンスが変わった時にテストでfailして気づけると嬉しいね。

調べた感じこれはできないことも無いんだけど、このテストが失敗するタイミングってバックエンドの実装が変わった瞬間で、フロントはそれのおかげで手戻りとかが起きるのが目に見えててかなり嫌です。
テストって実装に対してのチェックが行われるべきで、フロントのテストなのに知らないうちに壊れてる可能性があるのはテストとしてかなり厳しい。
2回めになるけど、バックエンドの実装にフロントの開発フローがべったり依存してるのは分業の意味がなくなるので嫌です。

フロント側の事情を述べてきましたが

SwaggerUIが便利だとかOpenAPI Schemaを書きたくないというのももちろん分かるし、もしスキーマ駆動になったら環境づくりが大変だとは思うんだけど、俺はどうにかもうちょっとフロントの開発が楽になるフローを採用したいです。

Barifac見てて結構つらいところが多そうに感じたので文面に起こした。実際どんな開発フローを採用するかに関してはまた話し合いさせてほしい。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants