新規開発の場合、フロントとサーバサイドのリポジトリは分けるのでしょうか？

Question

新規開発でフロントエンドとサーバサイドのエンジニアで役割分担している場合、フロントとサーバサイドのリポジトリはどのように管理したら良いのでしょうか？

1.デザイン作成 -> 2.フロント構築(webpack) -> 3.サーバーサイド構築(フレームワーク)　という工程で作っている場合、フロントから作り始めるので、リポジトリを別々にしておりましたが、サーバーサイドを作り始めると、フロントもサーバーサイド側で作業した方が効率的なように感じます。

あるタイミングからフロントとサーバーサイドのリポジトリは一緒にしたりするのでしょうか？

Comments

[hentaiman]

バラバラ管理で良いいならバラしたままでいいしフロントとバックが密な関係なら一緒にせざるを得ない
そしてそれらの情報を知るのは質問者と開発メンバーのみです。よって携わっているプロジェクトがバラして管理した方が良いかセットで管理した方が良いか、開発メンバーに相談するのが回答を得る唯一の手段です

[DeepRoastBeans]

なるほどですね、ありがとうございます。

[yumetodo]

フロントとサーバーは同じ言語で書くのですか？

[DeepRoastBeans]

異なる言語です。

Answer 1

フロントエンド先行、特にSPA方面へ行くならば分離した方が良いでしょう。
これはマイクロサービスの考え方で、責務を分離させて粗結合にした方が後々楽です。

単純に別々のリポジトリ管理で別々のタグを打てますからね。
バックエンドだけ不具合で速度が出ない時にバックエンドのバージョンだけダウングレードするけど、
フロント側は最新のデザインで運用するという事も可能です。

逆も然り、フロントでレイアウト崩れが出たらダウングレードしたいでしょうしね。

---

他にも例えばフロントもバックエンドも全てNode.jsでやっていたとして、
負荷が増えてきたから一部のエンドポイントをGo言語に切り出そう！みたいな話になることもあります。
同じプロジェクトの場合はもう無理というか大混乱になります。

そして更にこのエンドポイントだけは機械学習の成果を使うから、
Pythonにしなきゃダメなんだよ！！という要件も追加で出たとしましょう。
どうすんねんって話になります。

プロジェクトを分けていればかなり楽な話になります。
リバプロとしてNginxに80番ポートを使わせます。
そこからHTTPリクエストのパスを解析して、
フロントエンド配信用のNode.js、バックエンドNode.js、Go言語、Pythonに中継する。

まぁ、そんな要件99%ないやろな例え話ですが、
サイボウズのさようなら ImageMagickにこのような事例が載っています。
切り札の一つとして抑えておくと、デモデモダッテに囚われない発想で問題を解決出来るかもしれません。

---

まぁ、最初からRubyのRoRでやるんだとか、
PHPのLaravelでやるんだとか

企業の都合等で特定のWebフレームワークで完結するとわかりきっているプロジェクトの場合、
リポジトリを分けるメリットも殆どないと思います。

Comments

[DeepRoastBeans]

なるほどですね、フロントとサーバ側で役割・責務が異なる場合、バージョン管理も別々にした方が望ましいんですね。
サービスの規模が大きくなったり運用期間が長くなると、おっしゃる通り、複数言語のエンドポイントというのも十分あり得ると思いました。非常にわかりやすいご回答ありがとうございます。

Answer 2

フロントとサーバーで同一言語で開発する場合(ex. Node.js, ASP.NET, etc...)、コードが共通化できるため、同一レポジトリで、ということもあり得るかもしれません。その場合でも共通部分を別パッケージに切り出すことが多い気もしますが。

そうではない場合は、レポジトリは分けるほうがいいと思います。サーバーとクライアントの間のやり取りは結局の所HTTP通信ないしWebsocketになるのですから、その通信の仕様をOpenAPIかなにかで記述してそれを元にモックサーバーを自動生成してクライアントのテストをするのがいいでしょう。

Comments

[DeepRoastBeans]

フロントとサーバサイドが同一言語でも切り出すことが多いんですね。非常に参考になりました。ありがとうございます。