🌷

【卒業制作】本リリース時点での実装内容まとめ②(実装機能/gem編)

2024/08/22に公開

はじめに

前回この記事で、【卒業制作】本リリース時点での実装内容まとめ①(UI編)を投稿しました。
今回はその内容の続きで、MVP後〜本リリース間で実装した機能とそのgemの選定理由を投稿します。
gemの選定理由は、私自身で考えた結果を投稿しておりますのでご了承いただけますと幸いです。

サービス名: Miniita(ミニータ)

今回は本リリース時点の内容になるため、MVP後〜本リリース間での内容になります。
MVP以前の内容や前回の記事に関しては、下記にまとめておりますのでこちらご参照頂けますと幸いです。

本リリース時点で実装した機能

下記がMVPリリース後、本リリースまでに追加した機能になります。
各機能で記事を投稿しているものはその記事URL、記事を投稿していない場合は関連issueを掲載しております。

機能 詳細 実装方法 備考
認証
GitHub認証 実装記事①
実装記事②
SorceryのExternalを使用
投稿
MiniitaBot(チャットボット)機能 issue #121
Session_timeout機能 実装記事
コメント
コメントへのいいね機能(非同期) 実装記事①
実装記事②
マイページ
ユーザーバッジ画面 実装記事
継続サポート画面 issue #122
通知機能
自分の投稿へいいねされた時 issue #123
自分の投稿へコメントされた時 issue #123
自分のコメントへいいねされた時 実装記事
ユーザーバッジが付与された時 実装記事
その他
ユーザーバッジのXシェア機能 issue #124
全体的なUI調整

本時点で使用したgem

本リリースでは、チャットボット機能をOpneAIのAPIを使用して実装しました。
本リリース時点で新たに追加したgemは、下記のみとなります。

gem 内容 備考
gem 'ruby-openai' OpenAIのAPIに特化したgem MiniitaBot(チャットボット)機能で使用

上記gemを選定した理由

こちらissue内容を重複する箇所ございますが、ご了承いただけますと幸いです。

なぜ今回OpenAIのAPIを使用するのか?

-> 記事を書くハードルを下げる、という観点から記事初学者が記事を書きやすい環境を整えるため。
技術記事を書いている最中、記事を投稿し終えた後の継続フォローでのChatBot活用をイメージしていました。

  • 記事を書いている最中: ChatBotで①記事のテンプレート作成依頼②記事内容の確認依頼③誤字脱字の確認依頼を送信することができ、投稿することへのハードルを下げる。
  • 記事を投稿し終えた後: 継続して記事を投稿し続けられるように、これまで投稿したタイトル内容に関して総評される機能を実装し、継続して投稿できるような環境を構築する。

API使用にあたり、検討したgem

そもそも何故gemを使用したのか?

  • 自力で実装する手間を省く(=APIの利用がgem使用することで簡便になる)ため。
    -> 卒業制作という時間の制約があるため、gemを使用しスピーディに実装するため。
  • エラーハンドリングがしやすいため。

検討したgem

  • APIを使用するため、HTTPリクエストを簡単に扱えるようにするgemの利用を検討しました。
    -> ruby-openai / net/http(標準ライブラリ) / Faraday / httparty

各gemの特徴

  • ruby-openai:OpenAIのAPIに特化したGem。内部的にはFaradayを使用している。
    非公式のgemだが、OpenAIのAPIに特化したGemという意味ではstar数2.6kで圧倒的。
    (他のgemのsta数は、多くて400starくらい。参考
    メリット:ドキュメント内容が豊富、OpenAIのAPIに特化、導入にあたって📚 Rails AI (FREE Book) というドキュメントも使用できる。
    デメリット:OpenAIのAPI特化ということで、汎用的なHTTPリクエストライブラリとは異なる(今後使用する可能性は低い?)、セキュリティ面では、別でgem導入が必要。(今回はすでに、パスワードリセット等実装しているためgem 'dotenv-rails'導入済み)

  • net/http(標準ライブラリ):Rubyの標準ライブラリであり、追加のGemが不要。 HTTPリクエストを作成するための基本的な機能が提供されている。
    メリット:標準ライブラリであるため、外部依存がなく、軽量
    デメリット:コードが複雑になる可能性があり、HTTPリクエストの作成やエラーハンドリングが手間取る可能性ある。

  • Faraday:ミドルウェア(アプリケーションとその外部のサービス(例えば、データベースやAPI)との間でデータのやり取りを仲介するソフトウェア)を使ってロギングやタイムアウトなどの追加機能を簡単に統合できる。
    メリット:高度なカスタマイズや複雑なHTTPリクエストの設定が必要な場合に適している。

  • httparty:簡単にHTTPリクエストを作成し、レスポンスを処理できる。
    メリット:APIリクエストの処理が簡単で、他のAPIとも連携しやすい。汎用的なHTTPリクエストライブラリである。

検討した結果、ruby-openaiを採用

  • OpenAIのAPIに特化しているため、HTTPリクエストライブラリより導入がわかりやすいと感じたため。
  • 内部的にFaradayも採用しており、拡張性が高いと感じたため。
  • 懸念点としては、今後使用する可能性が低い、自力でAPIレスポンスを受け取る実装をできないこと。

最後に

今回は本時点で実装した機能とそのgemの選定理由について投稿しました。
最後までお読みいただき、ありがとうございました。

Discussion