GitHub ota42y
Comment8
Like
Created atMarch 24, 2018 11:09
Updated atMarch 24, 2018 11:09

Questions and feedbacks (8)

ota42y
ota42y commented 4 months

長期間Railsアプリを運用するとcontrollerやmodelに新旧様々なロジックが入ってしまいます。 こういった巨大なcontrollerやmodelを整理する良いコツはありますか。

特に複数のmodelを利用する処理の扱いが難しく、Userオブジェクトのようないろんなところに関連するモデルが肥大化したりします。

Like(3)

ota42y
ota42y commented 4 months

Webのフロントエンドはマイクロ化できますが、iOS/Androidアプリの場合はどのように解決されているのでしょうか

Like(2)

ota42y
ota42y commented 4 months

デザインの統一やボタン配置といった、複数のチーム間で揃えないといけないユーザ体験はどのようにコントロールしているのでしょうか

Like(1)

ota42y
ota42y commented 4 months

別の組織が作った別のサービスの更新が把握できずにトラブルになったりしましたか?また、その対策としてサービス横断で連絡するしくみを設けたりしていますか?

APIの破壊的変更や挙動が変わったことによる障害みたいなのは過去はたびたびありました。 ただ、他のチームの変更に追従を必須とすると他のチームの実装完了になるまで新しいAPIをリリースできなくなるため、マイクロサービスの数が増えると現実的ではないです。 FiNCでは基本的には過去のAPIの後方互換性は崩さず、そのような場合は新しいバージョンのAPIを作ってそっちに移行を促すという方針で行っています。 この方針ではチームは新しいAPIを気にせずリリースできますし、古いAPIを利用するチームは自分たちのタイミングで移行ができるようになります。 変更したいチームが使っているチームに対して直接通知したり、基盤に近いものに関してはプレゼンの中にもあった横断的に課題解決をする集まりで通知しています。

ただ、古い仕様をなかなか捨てられなかったり、deprecated連絡をするのが大変だったりと多少の問題が残されているため、何手か更に対応が必要かなと思っています。

Like(0)

ota42y
ota42y commented 4 months

Railsはサーバとして立ち上げるのはnodeなどに比べると煩雑な気がしますがそのようなRailsとマイクロサービスのかみ合わせの悪さみたいな経験があったりしますでしょうか?

FiNCはほぼ全てのマイクロサービスがRailsでできているので、インフラ面では特に困ったことは無いです。

アプリケーション面では、確かにFiNCにおいて必要な設定やgemを入れるのが大変なのですが、社内用のアプリケーションテンプレートを使ってすばやく作れるようにしています。 https://www.slideshare.net/takafumionaka/applicationtemplate

また、最近はdocker-composeで開発環境が整うようにする動きが起きていて、新しく入った人でもとりあえず作業ができる状態までの時間は短くなるような対策を打っています。

なのでRailsでマイクロサービスの立ち上げが困難というのはあまりないです。

Like(0)

ota42y
ota42y commented over 1 year

範囲検索で二つ目のインデックスが効果ある場合(ICP狙いの場合)って具体的にどういう場合なのでしょうか?

Like(0)

ota42y
ota42y commented 4 months

3人スタートアップだとどれくらいの数のマイクロサービスだと行けそうでしょうか?(一概には言えないと思いますが、今までの経験からのお答えで大丈夫です)

それぞれのマイクロサービスの規模やフロントにどれくらいの重きを置くのか、変更がどれくらい行われるのかとかでもの凄くぶれますが、2〜3個が現実的にできる数かなと思います。

Like(0)

ota42y
ota42y commented 4 months

サービスを横断する場合の機能開発時は複数のrails立ち上げ+お互いが疎通できるようなport設定などが発生すると思うのですが、 このあたりの手間をいい感じに省略できる文化とかはありますか?

FiNCでは複数のRailsを立ち上げて開発することがほぼありません。 Railsを複数立ち上げてそれぞれ正しい初期データを入れて開発するのは作業の面でもマシンスペックの面でも難しく、かなり初期の段階から諦めました。 そのため、FiNCではAPIの仕様をしっかりと定義し、他のマイクロサービスは想定した結果を必ず返してくれるという前提のもとで開発していくことが多いです。

ただ、アプリのバックエンドとしてAPIを作ることが多く、別サービスへのアクセスをモックしたユニットテストで開発がほぼできるという前提があります。 そのためフロントエンド開発では必要最低限のサービスを同時に立ち上げることがあり、その場合の知見はそこまで溜まっていないです…

Like(0)

This software is available as open source under the terms of the MIT License.
Copyright © 2018 Yoshiyuki Hirano