【設計編】Django REST framework (DRF)チュートリアル-Slack風サービスを開発する-

【設計編】Django REST framework (DRF)チュートリアル-Slack風サービスを開発する-

title通り、Slack風のサービスをDRFで開発していきます。
大まかな流れは以下になります。長いので別記事にして投稿予定です。

  • 【設計編】開発するものの概要や簡単な設計書の紹介(本記事)
  • 【基本編】簡単なCRUDのAPIを作ってみる
  • 【応用編】ちょっと特殊な部分を説明
  • 【TEST編】DRFのTESTについて
  • 【CI編】Circle ci , Heroku でサーバーにあげてみる
  • 【Front編】vue.jsで実際にAPIのbindingをしてみる

ここでは実際に開発に入る前に、どのようなサービスを作るのか、そしてどのような設計をすると開発がスムーズにいくのかについて説明します。

サービス概要

今回はtitleにもある通り、slack風のChatサービスを実装していこうと思います。slackを知らない人もいるかもしれませんが、簡単には以下のことができるサービスを実装します。

  • loginが必須のサービス
  • loginはgoogleアカウントで行う
  • Threadは誰でも作成できる(2chのスレのイメージ)
  • threadの編集、削除はそのThreadを作成した人だけが可能
  • Threadはprivate,publicの二種類がある
  • publicなthreadは誰でも参加可能
  • privateなthreadの場合にはThreadを作成した人だけがユーザーをそのスレッドに追加することができる
  • thread内ではcommentをすることができる
  • commentの編集、削除可能はそのcommentをした人だけが可能
  • commentは文字のみ、画像やmentionはなし
  • threadの検索はできるがpublicなthreadのみ表示させる
  • threadのメンバーはthreadのメンバー一覧を参照可能
  • もちろん特定のthreadのコメントだけを表示させることが可能
  • 退会機能はなし

もちろん、slackではこれ以外にも通知機能やpin留め、mentionなどなど様々な機能があったり、上記だけでは不便なサービスですが、今回はDRFのことを知ってもらうために最低限の機能を実装しますのでよろしくお願いします。(余力があれば機能追加します。?)

画面設計

本来であれば要件定義書などが必要ですが、今回は面倒な部分は省いていきなり画面設計です。

細かいUIなどはAPIの設計では関係ないので見た目は悪いですが、以下の4画面を開発します。

top page, comment list
create thread page
edit thread page
search page, search thread and comment

ER図作成

普段の開発でもER図というかDBの設計はとても大切ですが、REST APIでは特にTable一つ一つに対してCRUD(Create,Update,Read,Delete)のAPIを作るのでDBの設計はとても重要になります。
書き方は簡略化していますが個人ではこのくらいでいいでしょう。

ちなみにUser TableはdjangoのUser model を参考にしています。
https://github.com/django/django/blob/master/django/contrib/auth/models.py

chat app er

と言っても普段のDB設計で基本的にはOKです。キーはdjangoがid をdefaultで発行してくれるのでそちらを使います。indexなどは追々別記事で対応します。

API設計

ついにAPIの設計です。

と言ってもやることは簡単で、ER図を作成した時にできたTableに対してCRUDを考えていけばOKです。気を付けなければいけないのは、

  • Readに対して、filterやsortが必要な場合
  • login,Register,Logout
  • Page用のAPI

くらいでしょうか。上の二つについてはなんかめんどくさそうだなと思ってもらえると思います。

では、「Page用のAPI」とはなんでしょう?

それはREST APIに慣れている人はわかると思いますが、基本的にはREST APIで開発する場合にはtableごとにCRUDを作成します。

しかし、それだけだと、例えばyahooのような、Home 画面にNews,天気,交通情報,Hot wordなど様々情報がある場合どうなるでしょうか?
ひとつの画面を見たいだけなのにAPIを5個とか投げるとレスポンスが悪くなりがちです。なので、REST APIで開発する場合にも基本的には1Pageごとに対応するAPIを作成するのが普通です。
つまり、APIの設計をする時にはTableのCRUD以外に、画面用のAPIも考える必要があります。

以下が今回実装予定のAPI一覧になります。

URLMethod説明
/v1/threads/POSTthreadの作成
/v1/threads/GETthread一覧の参照
/v1/threads/1/GETthreadの詳細表示 pageのAPIで対応
/v1/threads/1/PATCHthreadの編集
/v1/threads/1/DELETEthreadの削除
/v1/threads/?q=aGETaをタイトルに含むThreadの検索機能
/v1/thread_members/POSTmemberを追加 複数もあり
/v1/thread_members/GET特定のThreadのmemberのみ見えればいいので実装しない
/v1/thread_members/1GETこれは不要
/v1/thread_members/1/PATCH参加するかしないかなのでPOST,DELETEだけでいいのでPATCHは実装しない
/v1/thread_members/1/DELETEthreadを退会したり、退会させたりする時に使う
/v1/thread_members/?thread=1GET特定のthread memberの一覧表示
/v1/comments/POSTCommentの作成
/v1/comments/GETprivateなThreadのコメントなどは見えたらダメなので、?thread=1などFilterは実装しますがこちらは実装しません。
/v1/comments/1/GETこちらは不要です。
/v1/comments/1/PATCHコメントの編集
/v1/comments/1/DELETEコメントの削除
/v1/comments/?thread=1GET特定のthreadのコメント一覧表示
/v1/page_thread/GETThreadをクリックしたときのAPIです。Thread memberの一覧とコメントの一覧を表示させます。
/v1/users/GET登録ユーザー一覧 ThreadのMemberを追加する時に使う
/v1/auth/login/google-oauth2POSTLogin,Register はGoogleアカウントを使う予定なのでここはsocial-auth-app-djangoというpackageに任せます。

URL の名前は複数形、先頭はversion,PUTは使わずにPOST,PATCHで対応します。必要のないAPIは実装しないほうが良いです。Security hole になりやすいです。本来であればpage api は実装しなくてREST API だけでも対応できるのですがここでは開発のTutorialのために入れています。(一画面表示のために2APIくらいであれば別に分けなくてもいいと思います。)

ここまでで設計編は終了です。

個人で開発する分には機能を考えて、画面設計を行い、DB設計をしてAPIの設計をするという流れでいいと思います。

それと画面設計やER図はdraw io を使って書きました。無料だし使い勝手も良いのでおすすめです。Google Driveから使えます。

では次は実際に上記のAPIの開発していきます。