0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

アプリケーションのプラットフォームをNext.js, FastAPIで作る

Last updated at Posted at 2024-11-11

はじめに

Next.jsとFastAPIを使って、アプリケーション一元管理できるWebアプリケーションを開発しています。
具体的には、「旅行」や「引っ越し」などの長期計画の「プロジェクト」に対して、それぞれのプロジェクトで使用するアプリケーションを自由に追加できるというシンプルなものです。
さらに、今後実装予定ですが、ユーザが作成したプロジェクトをテンプレートとしてアップロードできる、共有機能を実装します。これにより誰かが過去にやった経験を自分のプロジェクトに活用できるようにします。
アプリケーションごとに役割を持たせて情報リソースを管理し、それらを一元管理することで、情報リソースが分散しがちで着手するまでの心理的ハードルが高い長期計画プロジェクトの全体像を直感的に把握しやすくします。


プロトタイプ1(app_platform_v2):

プロトタイプ2(app_platform_v3):

目次

  1. 概要

    • プロダクトの概要
    • プロダクトのリンク

  2. 機能一覧

    • コア機能
    • 今後実装したい機能

  3. このプロダクトを作ろうと思ったきっかけ?

  4. アーキテクチャ

    • ファイル構成
    • ER図

  5. なぜその技術を選んだ?

    • FastAPIを選んだ理由(バックエンド)
    • Next.jsを選んだ理由(フロントエンド)

  6. 機能でこだわった点

    • 共有機能
    • 分析機能

  7. 苦労したところ

    • ただ既存のものを利用するだけではうまくいかない
    • Next.jsのルーティングとReactのレンダリングを理解すること
    • バックエンド、フロントエンドで別々のフレームワークを使ったこと

  8. 参考記事

  9. まとめ

1. 概要

概要

アプリケーションのアイコンを配置することで、長期計画に使用するサービスを一元管理できるプラットフォームを作りました。

例えば、旅行、就職活動、引っ越しなど、長期的な計画を立てる際には、複数のアプリケーションやサービスを利用したり、複数のウェブサイトを参照したりするため、情報が分散するといったことがよくあります。また、そのような計画は今取りかかるか迷うことも多く、後回しにしがちです。

このような課題を解決するために、「移動手段に関する情報はこのアプリに」「メモや参考サイトはこのアプリに」といった形でそれぞれのアプリケーションに役割を分担させ、それらのアプリを用途別に管理するプラットフォームを作ることにしました。


見てもらう方が早いかと思うので、まずはプロトタイプを紹介します。

プロトタイプ1(app_platform_v2)

  • アプリケーションを検索し、ブロック内に配置できます

2024-11-18 12.09の画像.jpeg


  • アプリケーションを配置した後のイメージです

2024-11-18 11.06の画像.jpeg

  • アプリケーションのアイコンをクリックすると、サイドバーが開き詳細を見ることができます
    2024-11-18 11.06の画像 (1).jpeg

プロトタイプ1では、ChatGPTに要件を伝えてとりあえずイメージを実際に形にしてみました。

作ってみた感想として、アプリケーションをブロックに配置するという機能自体は思っていたより簡単に実装でき、アイコンとブロックについてはuuidを使って状態管理できることがわかりました。

一方、ダッシュボード画面と編集画面は分けるべきだと考えました。また、アプリケーションのアイコンをドラッグ&ドロップで動かせるようにしたいという機能は必要ないと思いました。

理由は、今後詳細設計を進めていく上で既存のものを参考にしながら進めていく際、ブログアプリケーションを参考にしようと思ったからです。今回のプロダクトでは、ユーザーごとにプロジェクトの名前や「移動経路」「お店探し」など、ブロックに与えるタグ、アイコンの情報などをDBから取得することになるかと思います。その際、編集画面で新しいプロジェクトの名前、アイコンの名前をユーザーが入力する形式にした方がCRUDの実装がしやすいかと思ったからです。

ユーザーがアプリケーションのアイコンをドラッグ&ドロップで自由に配置するという、当初想定していた仕様も変更し、修正を加えたプロトタイプが以下になります。


プロトタイプ2(app_platform_v3)


デモの動画になります




主な使用技術
  • Next.js
  • Fast API
  • Chakra UI
  • App Router
  • React

使用した技術の詳細はrequirement.txtとpackage.jsonから確認できます。
https://github.com/takuto-abc/app_platform_v3/blob/main/backend/requirements.txt
https://github.com/takuto-abc/app_platform_v3/blob/main/frontend/package.json


2. 機能一覧

実装にあたり、ブログアプリケーションの機能を応用してアプリケーションの開発を進めたいと考えています。


プロトタイプで実装したコアの機能

「ここは外せない」という機能は以下のとおりです。

ダッシュボード
  • アプリケーションの詳細表示(右側サイドバー)
  • プロジェクト一覧表示(左側サイドバー)
  • ブロック内にアプリケーションを配置
編集
  • プロジェクトの追加・削除
  • ブロックの追加・削除
  • アイコンの追加・削除
  • プロジェクト、ブロックの名前の変更

今後実装したい機能
  • 共有機能
    • 自分のテンプレートを公開し、誰かのテンプレートも参考にできる
    • 誰かが過去にやったことを自分の計画に使えるように
  • いいね、保存機能
    • 誰かのテンプレートを保存したりいいねしたりできる
  • 分析機能
    • 今月よく使われたサービスやアプリケーションを分析しグラフで表示する機能
  • AIからの提案機能
    • サイト内だけでなく、外部サイトを参照してAIが目的にあったアプリケーションおよびテンプレートを提案してくれる機能

3.このプロダクトを作ろうと思ったきっかけ?

大学の夏休みや春休みによく友達と3泊4日で旅行に行くことがあるのですが、その際、「お金誰が払ったっけ?」とか調べ物、計画を立てるときの役割分担とかが曖昧になりがちでした。
そこで、最初からみんな共通のアプリケーションを使えば共通認識が生まれると同時に、アプリ間の連携(例えばPayPayで決済する、Notionで共同編集するなど)が可能になると考え、このアプリケーションを作ることにしました。これにより全員が同じプロトコルでやりとりするため確認がスムーズになり、特定の誰かが把握しなければならないような負担を減らすことにもつながります。

また、これは旅行以外のプロジェクトにも応用できると思います。例えば、就職活動でも「Notionで本選考やインターンの進捗管理をする」「イベントの応募はサポーターズ、長期インターンの応募はWantedly」「日程管理はカレンダーアプリ」「コーディングテスト対策はpaizaとAtCoder」「情報収集はYoutubeのTECH WORLD」「開発経験のアウトプットはQiita」・・・というように、パッと思いつくだけでもこれだけのサービスを使っています。正直これら一つ一つを把握し切るのは大変です。
しかし、長期計画においては目的が同じだとやり方が似通ってくるため、誰かが過去にやった経験を自分の長期計画に活かせたらかなり楽だと思います。共有機能ではこのようなニーズを実現したいと考えています。

さらに、ログイン時に「一般ユーザー」か「企業様」かでユーザーの属性を分け、個人だけでなく法人向けにも拡大できると面白いと思います。今の時代クラウドサービスが主流となってきており、SaaS企業の各分野に特化したサービスが数多く存在しています。特に、これまでシステムを外注してきた企業で、内製化を考えている企業にとって、このサービスは、

  • どのSaaSを使っているかひと目でわかり、費用の管理等もしやすくなる
  • 他社のクラウドサービス導入事例がわかる

というニーズを叶えることできると思います。

「ここのシステムは自社で開発したい」「この部分はSaaS企業のものを使いたい」といったニーズに対応し、SaaS企業のサービスをこのプラットフォーム上で一元管理し、他社の事例も確認できたなら、とても便利だなと思います。

4. アーキテクチャについて

ディレクトリ構成

2024-12-06 12.06の画像.jpeg

2024-12-06 12.07の画像.jpeg


ER図

名称未設定ファイル.drawio.png


5.なぜその技術を選んだ?

フレームワークについて

今回はフロントエンドにReact、バックエンドにFastAPIを使用しています。

Reactを選んだ理由について
  • ユーザーが動的にアイコンを動かせる仕様を実装したいと思ったから
FastAPIを選んだ理由
  • Pythonに慣れていたから
  • OpenAPIでAPI仕様を可視化できるから
  • データ分析、AIを使ったサービスの拡張ができるから

6. 機能でこだわった点

  • 共有機能
    • 自分が今からやろうとしていることは、既に誰かがやっている
    • 単なる業務効率化アプリではなく、SNSの要素も
  • 分析機能
    • Pythonを使うメリットを活かす

7. 苦労したところ

  • ただ既存のものを利用するだけではうまくいかない
  • Next.jsのルーティングとReactのレンダリングを理解すること
  • バックエンド、フロントエンドで別々のフレームワークを使ったこと

8. 参考記事

FastAPIの学習をするなかで、新しく学んだことを以下の記事にまとめています。

IMG_8172.jpeg

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?