Skip to content

6-DB開発・実装.md

Latest commit

 

History

History
108 lines (97 loc) · 7.04 KB

6-DB開発・実装.md

File metadata and controls

108 lines (97 loc) · 7.04 KB

DB関連を実装する

  • DB関連処理はDBの定義実装のフェーズ時にRead・WriteのDBインターフェイスを実装する
  • 後はGit業務フローを参考にしてプルリク・マージする
  • AWSのRDSからデータを取得する
    • AWS RDSなどを調べる
    • DB設計を調べる

データベースを設計する

  • データ型を調べてテーブル設計に反映する
  • テーブル設計
  • ER図作成

GoでDBを操作するコードを実装する

  • DBに使うデータ型を実装する
  • 入れ子に対して検索できるかテストする
    • テスト関数をデプロイして検証する

バグフィックス-1

  • 結果のタイトルが取得出来ていない
  • 検索条件が間違えているかも知れないので試す
  • GORMのSQL操作が問題だからコスト削減をする為にRDSからローカルに切り替えてテストする
    • RDSとVPCをまとめて削除する
    • VPCはLambdaとRDSが削除できたら削除する
  • ローカルではmysqlからsqliteに切り替える
  • ローカルでPDCAを回して機能を完成する
  • 配列を取得できるが、配列の中身が取得できていない
    • 出来たが、UNIQUE constraint failed: db_test_site_feeds.idでインサート出来なくなる
  • GORMで使う構造型のメンバは大文字で始めないといけない
  • GORM公式のチュートリアルを実行して動作を確かめる
  • リレーションなテープルを読み込むにはPreLoadを使う
    • これで配列の中身が取得できた

DBRepoを整備してテストコードを実装する

  • Read系はDBを読み込んで返すだけのもっとも軽い処理
  • Write系はUser関連の処理を実装する
    • Readよりは重い処理だが、Heavy系よりは軽い処理
  • Heavy系はサイトの取得・加工・DB登録処理を実装する
    • これが一番重い処理
  • Batch処理はHeavy系の処理を定期的に実行する
    • フィード更新・ランキング更新・トレンド更新などDBを定期的に読み込んで情報を更新する

Read系を実装

  • ランキング取得で新規仕様を実装
    • 今回は国をキーにしてランキングを取得する
    • 国とカテゴリーをキーにする機能は後日実装する
    • ランキングでそのサイトの購読者数を表示する機能があるから、サイトテーブルにそれの項目を付け足して購読者カウントはバッチ処理で実装する
  • ランキング機能は今の段階で実装してもサービス全体の価値向上につながらないから実装は次のバージョンに回す
    • だから、それ関連のコードは消すかここのフォルダに移動する
    • DB定義からも消すかフォルダに移動する
  • これでRead系が一つの機能しか実装していなくなった
    • 質問されたら、次のバージョンアップでReadにランキング・トレンド取得機能を実装する予定の為初期リリース時は一つの機能しか実装しない

Heavy（サイト）系を実装

サイト処理を実装

  • サイトの追加・存在確認・URL検索・サイト名検索

    • データベースでは負荷を軽減する為にフィードの配列はデフォルトでは読み込まれない
    • サイト取得フローを考えると、検索で表示するからフィードは必要無し

  • フィード取得をテストする

  • フィード取得フローをリファクタリングする

    • リクエストを追加した為、それにフローを合わせる必要がある
    • フローの中で、インターバルを入れて更新期限日時で更新するか判断するコードがあった
      • だが、いつ更新するかの判断はバッチ処理でやる。
      • このフローで判断することではない
    • それらの処理はバッチ処理に移した
    • もし、追加実装で記事更新が必要になったらハンドラーから追加して最新記事を取得する方式にすれば良い
    • APIFuncttion/FetchCloudFeedを改修する
      • Articleに既読かどうかのフラグがついていないのでArticleにフラグを追加する
      • フラグを更新する処理も入れるべきか

  • サイトの購読・確認のテストをパス

  • フィードの既読フラグはユーザーに属する情報だからユーザー系で処理する

    • 既読フラグもこの機能は非機能要件で優先度は低いので次のバージョンに回す

Write（ユーザー）系を実装する

  • まずは、DB接続処理を移植して実装する
  • Apiアクティビティを削除する
    • この機能はユーザーのアクティビティを記録する機能だが、これは非機能要件で優先度は低いので次のバージョンに回す

バグフィックス

  • UserとClientConfigを一緒に読み込めないので統合する
    • あまり深くなるとリレーション出来なくなるので、フィールドを並べておく
    • 更新が構造体ごとだと上手くいかないので、フィールドごと物理削除して新たに追加して更新とする

Batch処理を実装する

記事の更新など行う

  • 新規記事を取得してサイトの最終更新日時よりも新しい記事をインサートする

  • APIFunction/FetchCloudFeedをテストコードを合わせて改修してテストする

Lambda関数の役割がはっきりした為、Lambda関数名を変更する

  • Batch/Readは変更しない
  • Heavy系はサイト関連の処理が集中しているのでsiteに変更する
  • Write系はUser関連の処理が集中しているのでuserに変更する

各Lambda関数にデータ型をフォルダごとコピーする

  • 何か変更があればサイト関数で変更してから各関数にフォルダごとコピーする
  • この初期バージョンではユーザー識別情報は実装せずコードから退避させる