Railsにおける RESTfulなURL設計 勉強会で、RESTful APIとしてのRailsとクライアントとしてのJavaScriptというお話をさせて頂きました。
その際に、@tkawaさん、@t_wadaさん、@moroさんのお話を聞いた後に考えたことをまとめておきます。
- RESTful APIとしてリソース設計する際に、あまりにもRailsのmodel = ActiveRecordという考えにとらわれ過ぎると何でも非同期処理で取得したくなってしまうのでよろしくないということ。
- 非同期処理でユーザーの体験を良くしようとするつもりが逆に体験を悪くしていては本末転倒であるということ。
- 非同期処理でもn+1問題に気をつける
どうしてもリソースをActiveRecord単位のmodelで分割していると非同期処理で全てを解決しよう考えがちです。
例えば、私の考えた例ですと、/groups/1 にアクセスした際に /groups/1/posts へ非同期処理を行っていましたが、グループに投稿された記事の最初の一ページ目は /groups/1 を描写した際に同時に取得しておいたほうがユーザーにとっては良い経験を与えられるのではないかと思いました。
n+1問題に関しては、今回の例だと投稿記事にコメントが付けられるとしてその投稿を非同期処理で投稿の数だけ非同期処理で取得するような処理がそれに該当します。それを避けるには
- 各投稿に対して初めからhas_manyでコメントを取得する（これはサーバー側でn+1問題が発生するので
includes使うなど工夫が必要です) - 非同期処理で取得する際に画面に表示されている投稿の分をすべて一気に取得する(以前メンテしていたアプリではこれで対応しました)
といった対応が必要かなと思いました。ちょうどいま開発中ものを例にしていたのでその辺の仕組みを見なおそうと思いました。
その他何度も擦り込まれたお話としてmodel = ActiveRecord以外の論理モデルをリソースとしても良いということは目から鱗でした。これはRESTful Webサービスを読んだ際にも感じていたのですが、@joker1007さんのつぶやきでいろいろ繋がりました。
エンタープライズRailsを読んだ時は、データベースとアプリケーションが使うリソースにクッションになるオブジェクト層入れて、RDBMSのCRUDとは分離して捉えられるような構造を提案してた。 #sendagayarb
— Tomohiro Hashidateさん (@joker1007) 7月 23, 2012
そう、これエンタープライズRailsで読んだ！あの論理モデルをリソースにしてもいいよというお話だったんですね、これでスッキリ繋がりました。
いやーそれにしても濃い勉強会でした。Sendagaya.rb #9にて@tkawaさんにURLの設計相談をしたのをキッカケに開催することになったこの勉強会、開催してよかったです。発表者の皆様、参加者の皆様、会場提供頂きましたミクシィの皆様、ありがとうございました。
また、今回事前に相談内容を沢山いただきましたので次回は相談会をメインとした勉強会を開催したいと思っています。
