Day 3: API （サーバサイド） 技術部開発基盤 小室直 @hogelog

hogelog （小室 直） ● 2011/3 電気通信大学電気通信学研究科情報工学専攻 卒 ● 2011/4 株式会社ドワンゴ 入社 ● 2012/11 株式会社サイバーエージェント 入社 ● 2013/8 クックパッド株式会社 入社 ○ レシピ投稿関連の開発等（Web, Android) ○ 会員事業関連、OEM 向け API 開発等 (Web, Android) ○ 開発基盤（いろいろ）

Day 3, 4, 5 (8/29 - 8/31) ● チャットアプリケーションをつくっていきます ○ 3日目: サーバサイド ○ 4日目: クライアント ○ 5日目: インフラ

今日の内容 ● チャットアプリケーションの API 実装を通してサーバサイド の技術に触れ合っていきます

チャットアプリケーションとは ● クライアントとサーバ間で双方向に軽量のメッセージをラグ 少なく通信するアプリケーション ○ クライアントからのポーリングでも実装可能だが効率が悪い ● IRC, HipChat, Slack, LINE, Skype など古くから現在にいた るまで多くのアプリケーションが存在する

API の要求仕様 1. REST API a. チャット履歴取得、画像読み書き等 2. リアルタイムな WebSocket API a. リアルタイムなチャットメッセージ https://cookpad.github.io/cookpad-internship-2018-summer/slackpad-server/

要素技術 1. Rails 2. REST 3. WebSocket 4. RSpec

進め方 1. 要素技術の解説 (Rails, REST, WebSocket, RSpec) 2. チャットアプリ API 実装 3. 発表、まとめ

1. Rails

Rails とは

RTFM (Read The F****** Manual) https://tools.ietf.org/html/rfc1983#page-46

No content

概要だけ解説

Rails とは何か Railsとは、Rubyプログラミング言語で書かれた Webアプリケーションフレームワークです。 Railsは、あらゆ る開発者がWebアプリケーションの開発を始めるうえで必要となる作業やリソースを事前に仮定して準備し ておくことで、Webアプリケーションをより簡単にプログラミングできるように設計されています。 https://railsguides.jp/getting_started.html

Rails とは（雰囲気） ● MVC を基本とするフルスタック Web アプリケーションフレー ムワーク ○ Django, CakePHP, Laravel, Spring MVC 等 ● RESTful デザイン指向

Rails の哲学 ● 同じことを繰り返すな (Don't Repeat Yourself: DRY) ● 設定より規約 (Convention Over Configuration)

同じことを繰り返すな (Don't Repeat Yourself) DRYはソフトウェア開発上の原則であり、「システムを構成する知識のあらゆる部品は、常に単一であり、明 確であり、信頼できる形で表現されていなければならない」というものです。同じコードを繰り返し書くことを 徹底的に避けることで、コードが保守しやすくなり、容易に拡張できるようになり、そして何よりバグを減らす ことができます。 https://railsguides.jp/getting_started.html

設定より規約 (Convention Over Configuration) Railsでは、Webアプリケーションで行われるさまざまなことを実現するための最善の方法を明確に思い描い ており、Webアプリケーションの各種設定についても従来の経験や慣習を元に、それらのデフォルト値を定 めています。このように ある種独断でデフォルト値が決まっている おかげで、開発者の意見をすべて取り入 れようとした自由過ぎる Webアプリケーションのように、開発者が延々と設定ファイルを設定して回らずに済 みます。 https://railsguides.jp/getting_started.html

Rails と Rack Rackは、Rubyのウェブアプリケーションに対して、最小限でモジュール化されていて、応用の効くインター フェイスを提供します。 RackはHTTPリクエストとレスポンスを可能なかぎり簡単な方法でラッピングすること で、ウェブサーバー、ウェブフレームワーク、その間に位置するソフトウェア (ミドルウェアと呼ばれています ) のAPIを一つのメソッド呼び出しの形にまとめます。 Rails.applicationRails.applicationはRailsアプリケーションをRackアプリケーションとして実装したもので す。 https://railsguides.jp/rails_on_rack.html

Rails と Rack ● Rails は Rack という Ruby 向けウェブアプリケーション用イ ンターフェースに乗った形で実装されています ○ そのため Rack 向けライブラリや資産をそのまま Rails 用に使えます

Rails の優れたところ ● Rails の用意した道 (Rails Way) に乗ることで、素早く高速 にウェブアプリケーションを実装することができる ● Rails はウェブ最新の機能もどんどん取り込んでいく

Rails の気をつけるところ ● Rails は変わり続ける ○ 古い Rails のメンテナンスはそのうち止まる ○ Rails アプリケーションは最新 Rails に追随し続けなければいけない ● 機能を実装する速度に注力したフレームワーク ● 全てが Rails Way の上で実現できるわけではない

2. REST (Representational State Transfer)

（狭義の）REST とは ● リソースへの操作の組み合わせとしてアプリケーションを実 装していくアーキテクチャ ● （多くの場合）リソースへの操作は HTTP POST/GET/PATCH/DELETE リクエストで実行される ● 全てのリソースはユニークな URL を持つ

REST API ● REST の思想に沿って設計された Web API ○ Web API の設計方針としてデファクトスタンダード ● Book リソースを扱うなら以下のような URL となる ○ POST /books ○ GET /books, GET /books/:id ○ PUT /books/:id ○ DELETE /books/:id

Rails と REST リソースベースのルーティング (以下リソースルーティング ) を使用することで、リソースベースで構成されたコントローラに対応する共通のルーティングを手軽 に宣言できます。リソースフルなルーティングを宣言することで、コントローラの index、show、new、edit、create、update、destroyアクションを個別に宣言し なくても1行で宣言が完了します。 ブラウザはRailsに対してリクエストを送信する際に、特定の HTTPメソッド (GET、POST、PATCH、PUT、DELETEなど) を使用して、URLに対するリクエストを 作成します。上に述べた HTTPメソッドは、いずれもリソースに対して特定の操作の実行を指示するリクエストです。リソースルーティングでは、関連するさまざ まなリクエストを1つのコントローラ内のアクションに割り当てます。 Railsアプリケーションが以下の HTTPリクエストを受け取ったとします。 DELETE /photos/17 このリクエストは、特定のコントローラ内アクションにマッピングさせるようルーターに要求しています。最初にマッチしたのが以下のルーティングだとします。 resources :photos Railsはこのリクエストをphotosコントローラ内のdestroyアクションに割り当て、 paramsハッシュに{ id: '17' }を含めます。 https://railsguides.jp/routing.html

Rails と REST ● Rails は REST 考えに基づいている ○ 考えに沿ってアプリケーションを設計をすると実装が簡潔になる ● Book リソースの URL ルーティング定義は一行に ○ resources :books ■ POST /books ■ GET /books, GET /books/:id ■ PUT /books/:id ■ DELETE /books/:id

（余談）REST API 以外の選択肢 ● gRPC ○ 分散システム上で動く RPC フレームワーク ● GraphQL API ○ GraphQL と呼ばれるクエリを受け取る API ● XML-RPC, SOAP, … ○ 色々あります（ありました）

3. WebSocket

WebSocket とは The WebSocket protocol enables interaction between a web client (such as a browser) and a web server with lower overheads, facilitating real-time data transfer from and to the server. WebSocket プロトコルはウェブクライアント（ブラウザなど）とウェブサーバーの相互 通信を可能にし、オーバーヘッドを削減し、サーバーとのリアルタイムのデータ転送を 容易にします。 https://en.wikipedia.org/wiki/WebSocket

WebSocket ● クライアントとサーバ間の双方向通信プロトコル ○ HTTP 上で実現されているプロトコルではない ○ 接続確立時のみ HTTP のようなハンドシェイクがやり取りされる ● IE, Firefox, Chrome, Safari, Edge 等各種ブラウザ対応 ○ ReactNative も https://facebook.github.io/react-native/docs/network#websocket-support

Rails と WebSocket ● Action Cable が Rails 5 から導入 Action Cableは、 WebSocketとRailsのその他の部分をシームレスに統合するためのもので す。Action Cable が導入されたことで、 Rails アプリケーションの効率の良さとスケーラビリティ を損なわずに、通常の Railsアプリケーションと同じスタイル・方法でリアルタイム機能を Rubyで 記述できます。クライアント側の JavaScriptフレームワークとサーバー側の Rubyフレームワーク を同時に提供する、フルスタックのフレームワークです。 Active RecordなどのORMで書かれた すべてのドメインモデルにアクセスできます。 https://railsguides.jp/action_cable_overview.html

WebSocket 実装 ● 各種言語、フレームワークでのサポート ○ C++, Java, Go, Elixir, Node, Ruby, ... ■ https://github.com/facundofarias/awesome-websockets ■ https://hashrocket.com/blog/posts/websocket-shootout ○ 要件と仕様にあった選択が大事

（余談）WebSocket 以外の相互通信 ● ポーリング ● Comet （ロングポーリング） ● Server Sent Events ● MQTT, …

4. RSpec

RSpec ● https://rspec.info/ ○ 最新のドキュメントは https://relishapp.com/rspec ● Rails, Ruby で人気の高いテストフレームワーク

TDD (Test Driven Development) ● アプリケーション、コードのふるまいを記述した「テスト」を軸 とした開発手法 ○ 開発手法であってテスト手法ではない ● 今回はあまりやりません

テストに関する資料　 ● Rails テスティングガイド ○ https://railsguides.jp/testing.html ● クックパッド サマーインターンシップ2017 TDD ○ https://speakerdeck.com/moro/cookpad-17day-tech-internship-2017-tdd ● RSpecの入門とその一歩先へ ～RSpec 3バージョン～ ○ https://qiita.com/jnchito/items/624f6d5023c279046a1c ● Better Specs ○ http://www.betterspecs.org/

まとめ

公式ドキュメントを読もう (RTFM) ● Ruby https://docs.ruby-lang.org/ ● Rails https://railsguides.jp/ ● RSpec https://relishapp.com/rspec

後半へ続く チャットアプリ API 実装 https://cookpad.github.io/cookpad-internship-2018-summer/slackpad-server/lecture/