GitHubリポジトリ

概要

毎日、その日のやったこと・よかった点・改善点・明日何するかなどのフォームに答えることで、その日のまとめ（日記）を作成してくれて1日の最後に振り返りができるwebアプリを作る。
また、次の日何をするか（タイムスケジュール、タスク）も見られることで、次の日のやることもはっきりさせる。
まずは自分で使う用に作る。

なぜ作ろうと思ったか

• 毎日振り返りのために日記を書いているが、フォーマットがバラバラのためまとまりがなかったり読みづらかったり、改善点が次の日に活きていないと感じるから
• 1日の初めに何をするか決まっていた方が朝も起きやすいし始めやすい、時間を無駄にしない

機能

• ログイン機能
• 「日記を書く」機能
  • 「日記を書く」ボタン押すと、フォームが出てきて答えると日記を作成してくれる
    • 予定していたタイムスケジュールと実際に行ったタイムスケジュールを比較できる
    • 出力された日記は記録され、テキストをコピーできるボタン設置
    • フォーム項目
      • 今日やったこと
        • 実際のタイムスケジュールを作る
          • 「今日のやること」（下部参照）の今日のタイムスケジュールがあるならそれを編集する
        • 「今日のやること」のタスクのうちできたことをチェック
          • 「今日のやること」画面でもうチェックしている内容はチェックがついている
          • 追加でやったタスクをここでも追加できる
      • 今日の良かった点
      • 今日のよくなかった点
      • 明日以降に改善したい点
      • 明日やること
        • 予定タイムスケジュール
        • 予定タスク
      • フリーコメント
• 「日記を見る」機能
  • 過去に書いた日記が見られる
  • 日記はテキストにしてコピーできる
  • 日記は編集・削除できる
• 「今日のやること」機能
  • 前日のフォームの「明日やること」欄に書いたことを「今日のやること」として見られる。
    • 「今日のやること」は新規作成（前日書いていなかった場合）・編集できる
    • 「今日のやること」
      • タイムスケジュール
      • タスク
        • チェックできるようにする
      • 昨日の改善点も表示する
• 「ToDoリスト」機能
  • ToDoリスト
    • やる日程を設定できる
  • 「今日のやること（やったこと）」のタスクと連携される

ポイント

• 質問に答えた内容を分析をしてくれるわけではなく、あくまで答えた内容をフォーマットを揃えてまとめてくれる。次の日何するかは自分で設定する。
• シンプルな作りにする

今後の展望

• web版とモバイル版両方作るかも？まずはweb版作る
• タスクの達成率表示機能追加？
  • タスクをカテゴリ分けしてカテゴリごとにまとめるのもあり
• googleカレンダー連携してもいい
• 日記をつけたらスタンプがつく。夏休みのラジオ体操のスタンプカード的な

API一覧

• 日記閲覧/get
• 日記閲覧（id指定）/get
• 日記作成/post
• 日記更新/patch
• 日記削除/delete
• todo閲覧/get
• todo閲覧（id指定）/get
• todo作成/post
• todo更新/patch
• todo削除/delete
• user作成/post
• userログイン/post
• user更新/patch
• user削除/delete

API仕様書を作る

OpenAPIを使ってAPIの詳しい仕様を決める。

Swagger（OpenAPIを実装するためのツール群）を使う。
まずはSwaggerEditorでYAML形式で仕様書を書く。
（わかりやすくて参考になる記事）

idの振り方

ユーザーidなどのidは連番？タイムスタンプから生成？
→uuidを使うのが良さそう！

なぜなら、

• 連番・タイムスタンプから生成だと、将来的に別のデータベースと統合したいとなったときに、idが被るとidの置き換えが必要になり大変だから。
• 連番だと予測ができてしまうので、システムによっては悪用される可能性もあるから。

など。

HTTPリクエストにおけるヘッダーとボディの役割の違いは？

• リクエストヘッダーはリクエストのメタデータを持つ。
  • 例：ホスト名、Cookieなど
• リクエストボディはリクエストの本文データを持つ。
  • 例：POSTデータ、アップロードしたファイルのデータなど

今回は

• ログインしているユーザーを示すためにuserIdを渡す→ヘッダー
• ログイン時のemail・passwordなど→body

にする。
userId・email・passwordなど大事な情報は、ユーザーには見えないようにクエリ文字列には入れない。
また、ログインできたらAPIはユーザー情報を返すが、passwordは安全のため返さない。

SwaggerUIを起動

API仕様書が書けたので、docekerでSwaggerUIを起動してみる。
dockerファイルの書き方をおさらいしていこう。

参考サイト

dockerファイルで使っているポートって何？

8000:8080なら、ポート8000番にアクセスすれば繋がる。8080番は、コンテナ内で実行されている該当アプリケーションが待機しているポート番号。ホスト側の 8000 ポートにアクセスすることでコンテナ内の 8080 ポートにリクエストが転送される。

dockerファイルのvolumes セクションって何？

ボリュームマウントというもの。ホスト（PC）にあるファイルをコンテナ内にマウント（共有）するためのもの。今回は以下のようにしてopenapi.yamlをコンテナに共有している。

volumes:
      - ./api/openapi.yaml:/openapi.yaml

dockerファイルのenvironmentセクションって何？

コンテナ内の環境変数 SWAGGER_JSON に /openapi.yaml を設定している。
今回は以下の設定により、アプリケーションは SWAGGER_JSON 変数のパスを通じて、OpenAPIのドキュメントを /openapi.yaml から読み込むことができる。

environment:
      SWAGGER_JSON: /openapi.yaml

• SWAGGER_JSON: 環境変数の名前。アプリケーションがどのファイルを参照すべきかを指示している。
• /openapi.yaml: コンテナ内で参照されるファイルパス。volumes でマウントされたファイルのパスを指定しているため、ホストの openapi.yaml を指している。

volumesでopenapi.yamlをマウント（共有）し、それを環境変数に当てはめることで参照できるようになっている。

できた！！

backend環境の構築

NestJsで作っていく。以下でbackendディレクトリに作る。

nest run backend

dockerでbackendを起動できるようにした。

docker-compose up --build

参考にした記事

DBの環境構築

postgresqlを使う。
参考にしたサイト
Q: 以下の意味は？

volumes:
      - db-store:/var/lib/postgresql/data

→db-store:という名前のボリュームをホスト側に作成し、コンテナが停止・削除されてもデータが保持されるようにしている。
/var/lib/postgresql/dataはコンテナ内のDBデータが入っているパス。PostgreSQL が使用する。

TablePlusで接続チェックして、DBをdockerで起動できた！

TodoリストのAPIの作成

まずtodo新規作成のAPIを作る。
こちらの記事を参考にさせていただき作成した。

DTOの役割とは？

• データのやり取りが目的
• APIへのリクエストにバリデーションを追加する
• 必要なデータだけやり取りできる
  など。

Entityの役割は？

• データベースのテーブルの設計書
  など

APIリクエストが成功した場合のレスポンス

Todo登録の場合、Todo追加が成功した場合にはステータスコード200が返ってくればあとはいらないのか？
→追加したTodoの内容も返して、フロント側での更新処理に使ったりもするらしいが、今回は成功したことが分かればいいので、成功した場合にはステータスコード200だけ返すことにする。

環境変数の設定方法