見出し画像

モノリスなRailsアプリ『ツクリンク』で技術的に面白くなるところ（またの名を課題）

あっきー

※2023/02/28追記
情報をアップデートしたブログを書きました。

＊＊＊

ごきげんよう。ツクリンクでエンジニアをしているあっきーです。
Railsでサービス開発をして7年、サービスも大きくなり、エンジニアも増え開発体制が整ってきているなかで技術的な課題も増えてきました。
現在の課題から、個人的に今後やっていきたいと思っていることや所感を書いていきます。

※サービス開発の年数やその他、数字的な状況はこちらの記事にあります


🤖対象読者

  • Railsエンジニア

    • 特にRailsでモノリスなWebアプリを開発している方

  • ツクリンクに興味のあるエンジニア

    • フロントエンドやモバイルアプリなどの課題を見て挑戦したい方

🏃‍♂️忙しい方向けまとめ

開発の課題めちゃくちゃあるよ！助けて！

  • フロントはTS導入からコンポーネント設計やバックエンドとの分離検討

  • スタイルガイドやデザインシステムの設計、整備

  • モバイルアプリは書き直しや環境整備から

  • バックエンドはどこまでRailsを信仰するか検討

    • Hotwireを利用するのか

    • 認証基盤のマイクロサービス化

    • Goなど別言語の選定も視野に

  • メール・プッシュ通知配信の改善


⚛フロントエンド（React）

現状、複雑なフォームやリッチに動かしたい数ページのみReactを利用しています。
Reactを導入せずjQueryのみで動いている保守性の低いページが存在するためReact化を進めていきたいです。
その先ではユーザー体験を良くするためにもフロントエンド/バックエンドを分離したSPA化を検討していきたいと考えています。

また、TypeScriptが入っていないのでTypeScriptの導入も併せて検討。
RailsでのE2Eテストはありますが、フロントのテストは無いので余裕があればそこまで対応できると良さそう。
Webpackerを使っていますがRails7で消えるのでWebpackでの環境整備など、フロントエンドに強い方に基礎的な開発環境作りから力を貸していただきたいポイントです。

CSS：スタイルガイドやデザインシステム

TDS（TsukulinkDesignSystemの略🐭）というデザインシステムを作りFLOCSSベースにCSS設計を行っています。
開発効率向上やブランドイメージの作成、デザインの統一性を上げるために、デザイナーと協力してスタイルガイドやデザインシステムなどを整備していく必要があります。

現状のCSS設計については以下の記事を参照してください。

古いCSSも残っているため移行などの対応も必要です。
現状メインはFLOCSSベースで作られていますが最近のTailwindCSSなどのユーティリティファーストなCSSを見ているとある場面においては使いやすそうに感じ、CSS設計自体の再検討もしたいです。
個人的にはユーティリティばかりになるDOMが好みではないので折衷案が取れればいいなと思っています。

フロントエンド/バックエンドの分離

フロントを全てReactJSで置き換えていく可能性もあるとは思いますが、エンジニア採用の激化などを見ると、専属チームの採用自体が困難な状況で分離をする判断は難しく感じます。
開発組織として『技術的に新しい挑戦をする』ことと、チームを作りメンテナンスし続けられるかとのバランスを大事に、最終的には組織体制と合わせてどうしていきたいかの決めの問題だとは思います。
このあたりの記事も参考にしたいところです。

組織やユースケースを明確にして選定していく話。

チームとユースケースを明らかにせず「RubyなのかGoなのかRustなのか」「HotwireなのかReactなのか」という議論をするならば、それは片手落ちです。

https://zenn.dev/kenzan100/articles/0f9b100655a4bf#%E4%BB%8A%E5%BE%8C%E3%81%AErails


📱モバイルアプリ（iOS, Android）

WebViewがメインのアプリを出しています。
iOSはSwift、AndroidはJava
現在はバグ修正やOSのバージョンアップ対応などですが、モバイルアプリも強化していきたい。
どちらも7年前に作られていてほぼバグ修正がメインだったため、最近のデファクトスタンダードな環境・コードにはなっていないと思われます。Kotlinへの書き換えや根本的に再設計してから改修するなど足元を固める必要があります。

最近ではFlutterの盛り上がりもあり選択肢としてあると考えています。クロスプラットフォーム特有の問題もあるとは思いますが、先に書いたエンジニア採用の激化ということもあり、最小人数でプロダクトを効率的に作るということを考えると各プラットフォームをネイティブで作るよりもクロスプラットフォームの方がやりやすい可能性もあると考えています。

💎バックエンド（Rails）

Railsは6.1.6、Rubyは3.0.3と基本最新を追従できるようアップデートをしています。
また新規で参画したエンジニアから「理解しやすい」といったフィードバックをいただくこともありコードベースは品質良く保てていると思います。（一部古い実装や理解しづらい部分もありますが）

Rails7も出てHotwireを信仰していくかは怪しく、まだ検証していく必要を感じています。

フロントエンドを分離する場合、RailsがAPIに徹することになりますがそもそもRailsでいいのかという議論にもなりそうですが即時リプレイスは現実的ではないので移行方法や言語など検討する箇所が多く残っています。

認証基盤

アプリを強化したり、新規事業や関連サービス立ち上げて連携する場合はマイクロサービスとして認証基盤の作成も課題に上がってくると思われます。このあたりは特に知見のある方に協力いただきたいポイントです。

メール・プッシュ通知配信の仕組み

割と古めな実装が生きている箇所です。根本的な仕組みの考え直しからリプレイスや改善が必要です。

画像の最適化

ユーザーが投稿した画像のリサイズや圧縮など対応はしていますが、サイトのパフォーマンスにも影響が出るので更に良くしていきたいポイントです。

負荷対策、クエリ改善

まだクリティカルな問題は出ていませんがユーザー数やDBのレコード数の増加に伴いレスポンスが遅くなる可能性があります。
レスポンスが遅くならないよう、負荷対策やDBのチューニング、クエリの改善などDBやインフラ関係の改善を行っていきたいです。

バックエンドのテスト

カバレッジ90％弱とかなり優秀な状況なのでここは継続できるよう改善を続けたいです。

その他

その他雑多な気になることや改善したいこと

バグ報告、仕様問い合わせの品質向上

バグ報告で必要な情報を記入してもらえるようSlackワークフローを利用したバグ報告や問い合わせの仕組み化

全体的な開発体制の強化

人数が増えてもデリバリーまでの速さを担保できるような組織体制や仕組み
テスト・リリース手順高速化、QAチーム立ち上げ、CD/CIの最適化、技術者個々人のスキルアップなど

おわりに

雑多にやりたいこと、気になっていることを書いてみました。
まだ方向性がはっきりしないものも多く課題だらけです。
モノリスなアプリケーションで長くやっていると色々と課題が出てくると思います。
・同じ様な悩みを抱えている
・ツクリンクの開発について話を聞きたい
・なんとなく技術的な話をしたい
などあれば雑談しませんか？
Meetyを公開しているのでお気軽にご連絡ください。


ツクリンク株式会社では一緒に働く仲間を募集しています。


読んでくれてありがとうございます！少しでもいいなと思ったら「スキ❤️」してもらえると飛んで喜びます！シェアしてもらったらもっと嬉しいです！