Qiita Teams that are logged in
You are not logged in to any team

Log in to Qiita Team
Community
OrganizationEventAdvent CalendarQiitadon (β)
Service
Qiita JobsQiita ZineQiita Blog
13
Help us understand the problem. What are the problem?

More than 5 years have passed since last update.

posted at

updated at

Organization

再考 RESTful APIとしてのRailsとクライアントとしてのJavaScript

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で読んだ!あの論理モデルをリソースにしてもいいよというお話だったんですね、これでスッキリ繋がりました。

いやーそれにしても濃い勉強会でした。Sendagaya.rb #9にて@tkawaさんにURLの設計相談をしたのをキッカケに開催することになったこの勉強会、開催してよかったです。発表者の皆様、参加者の皆様、会場提供頂きましたミクシィの皆様、ありがとうございました。

また、今回事前に相談内容を沢山いただきましたので次回は相談会をメインとした勉強会を開催したいと思っています。

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
13
Help us understand the problem. What are the problem?