Rails5とAPIモードについての解説

【CoEdo.rb】Ruby/Railsビギナーズ勉強会#16

2016/09/25FumiyaSakai

自己紹介と簡単な経歴など

✦ 今までの仕事履歴（本業）

石川県金沢市生まれ

本業はサーバーサイドのプログラマ※Rails＆PHP使い

26歳〜32歳：　Webプログラマ（PHP&Rubyがキャリア長い）

23歳〜25歳：　Webデザイナー兼ディレクター

チャンスがあればiOSアプリ開発も絶賛やってみたい！

趣味：シルバーアクセサリー集め・スイーツ作り・アプリ開発

女子向け・グルメ・エンタメ関連のお仕事が多い

Qiita:http://qiita.com/fumiyasac@github

Github:https://github.com/fumiyasac

✦ 酒井文也（さかいふみや）

東京（大塚）住まいの32歳

こんな格好を普段からしているので遊び人に見られますがエンジニアです。

文系卒に思われますが実は数学科で理系卒です。

めっちゃお酒好きそうに見えますがビール苦手でお酒も超弱いです。

今でもたまにUIまわりとか触りたくなることがあったりなかったり

今年の4月からフリーランスです。（割とお堅い感じの会社にいます）

最近のはまっている食べ物はカボチャと担々麺と甘栗です。

最近はSwift以外ではRailsやLaravel・CakePHP・Node.jsなんかも

これまでに作ったもの（ネイティブアプリ）

①簡易家計簿アプリ「Coffre」

②ゲームアプリ「10秒虫食い算」

・カレンダーを自作しています

・シンプルなお小遣い帳感覚で支出管理できます

・全問正解者ほとんどいません…

・不定期ですがコラムも書いています

・サーバーサイドはRubyonRailsを使用

http://www.coffre.me/

・デザインにもこだわってみました（特にグラフ）

・実はちょっとバグがあります。

・問題は今後追加予定（現在110問収録）

個人的にはなりますが、他にもアプリ・Webサービスなど開発中です（2016年も宜しくお願いします）

・サイト等は次回のアップデートで公開予定

http://blog.just1factory.net/services/284

・若干の中毒性を含みます

人生で初めてiOSのライブラリを作りました

日本の祝祭日を計算で出してくれる

・カレンダーアプリ等での活用を想定

・シルバーウィーク・ゴールデンウィークも対応

・ハッピーマンデー法の施行も対応

・春分の日・秋分の日にも対応

・過去の祝祭日もおおむね考慮はしている

構想や基本実装は僕ですが、他に3名のContributorのお力添えがあり実運用できるレベルになりました！

職人の手作業で計算しております！

・HTTP(HTTPS)通信は不要

★CalculateCalendarLogicver0.0.2

【だが本業は今もサーバーサイドです】PHP(メインのframeworkはSymfony)&Ruby(Sinatraに近いもの?)

・Github:https://github.com/fumiyasac/handMadeCalendarAdvance

・実装解説:http://qiita.com/fumiyasac@github/items/33bfc07ad36dfffcdf8f

・Github:https://github.com/fumiyasac/handMadeCalendarOfSwift

✦ APIモードとは？

Rails5で実装されたAPIモード

参考：【Railsガイド】RailsによるAPI専用アプリ：

2.Webアプリとネイティブアプリでデータを共有することも増えてきている

Rails側でなんでも行ってくれる反面機能を絞った使い方をする場合にはちょっとゴツい場合もあります。

★API作成のために最適化された状態のRails

・ディレクトリ構成も従来のRailsよりもシンプル

・標準で入っているGemも少なくなっている

★従来までのAPIサーバーをRubyで実装する際

APIベースでビジネスロジックを実装したい時はSinatra等で構築するケースも

・APIアクセス用のエンドポイントを作成する

・Faraday/Grape等のAPI作成用のGemを使用する

【標準のサポートが強力ゆえにちょっと機能が過多な一面も】

・標準でjsonファイルをレスポンスとして返す想定

http://railsguides.jp/api_app.html

デフォルトのRailsはフロント周りのGem等が

始めから結構入っている。

1.APIサーバーだけを作る際はフロントまわりのGemは正直不要

参考：

（Faraday）https://github.com/lostisland/faraday

（Grape）https://github.com/ruby-grape/grape

✦ 例えばものすごくゴツいプロジェクトファイルを想像して下さい

なぜ機能ごとにAPI化する流れに？

それぞれを独立した機能としてAPI化してクロスプラットフォーム対応等特に大きくなるほど良さを発揮する

★この場合一つの部分にバグがあるとドミノ倒しで影響が出てしまう

★自分がこれまでの現場にて感じた機能ごとにAPI化するメリット

・データ量が多いDBのデータをAPI経由で取得することで負荷をうまく分散させる

・Webアプリとネイティブアプリで共通のデータを使うので原因の特定がしやすかった

プロジェクト○

【A/BをAPIに】

【API側のサーバーサイドの知識だけではなくフロントの技術も知らないといけない】

データの取得はAjax経由であったり他のJavascriptやサーバーサイドのフレームワーク経由で行うため

例）

・機能ごとに管理やテスト等も行っていた場合もあり安心感があった

個人的に実務の中においても特に大規模な開発ではそのメリットを享受できる面が多かった

【一部にバグ】

共通機能A○

共通機能B○

プロジェクト×

共通機能A×

共通機能B×

プロジェクト

共通機能API(A)

共通機能API(B)

共通機能は

特に根幹部分

共通機能は

APIとして使う

✦ 概念や考え方の紹介と実用例

マイクロサービスアーキテクチャとは？

特に大きなシステム構成になっている企業等では導入事例や積極的な推進を行っている感じがしていますね

★一枚岩の状態からの卒業

★マイクロサービス化をしている事例

・事例1)株式会社ネクスト：Zipkinを導入してみた（サーバー編）

http://nextdeveloper.hatenablog.com/?page=1467271464

モノリシックなアーキテクチャをビジネス機能によって複数の小さいマイクロサービスに分けて、

それらを連携させるアーキテクチャにするという考え方

参考：オライリー本の「マイクロサービスアーキテクチャ」より一部引用

1.素早いデプロイ

2.優れた回復性マイクロサービスアーキテクチャのメリット

3.スケーラビリティ

・事例2)株式会社Gunosy：マイクロにしすぎた結果がこれだよ！

http://www.slideshare.net/mosa_siru/ss-64839846

など…

✦ 二つの写真を見比べて見てください

マイクロサービスアーキテクチャのイメージ

正しい説明になっているかはちょっと自信がもてませんがこのように機能（料理）ごとに分けてしまう感じ

★マイクロサービス化する前と後を料理に例えるとこんな感じになると思います

before

・1個のお皿に詰め込んでしまうこの盛り付け方

　だと味が混ざってしまう

after

・それぞれの役割（前菜・メイン・デザート等）

　によってお皿を分けてしまう

✦ フロントまわり等の知識も必要になってくると思われる

APIモードではこんな時どうする？

参考：SPA開発をしてみてよかったこと（雑感）：

機能ごとにAPIにするアプローチの場合にはWeb・ネイティブの知識や知見があるといっそう良いと思います

★管理画面を作成する場合にはAjax化or他プログラムでの別途実装が必要

・Web側だとSPA(SinglePageApplication)化してデータを取得して表示

・他のJavaScriptフレームワーク(Angular.jsやReact.js等)を用いるケース

★今回の資料＆サンプルの参考文献

・Rails5のAPImodeを少し調べてみたhttps://www.hommax39.com/archives/170

・他言語のフレームワークを使ってAPIからデータを取得するケース

http://tech.trippiece.com/blog/2015/02/02/spa-development/

・HandlingfileuploadusingRubyonRails5APIhttp://tutorials.pluralsight.com/ruby-ruby-on-rails/handling-file-upload-using-ruby-on-rails-5-api

・Rails5apiモード+JSONAPIResourcesでAPIサーバを作るhttp://hkdnet.hatenablog.com/entry/2016/05/22/141553

✦ APIサーバーとフロント側のサーバーを用意して確認してみよう

ここからは実際のコード例を見ていきます

★導入手順やその他について

実際のRails側でのソースとファイルアップロードを行うサンプルを通じて実際の実装例等を見ていきます。

Github

・Rails5でAPIモードでプロジェクトを作成した際のサンプル

https://github.com/fumiyasac/rails-api-mode-sample

導入手順

$gitclonehttps://github.com/fumiyasac/rails-api-mode-sample.git

※こちらのサンプルに関してはフロント画面用の部分についてはnode.jsが別途必要になります。

$cdfrontend$naminstall$gulp

フロント側のサーバーを立ち上げるためにgulp等をインストールする

$cdapi/file_upload_api$railss-b127.0.0.1

Railsプロジェクトを起動する

・フロント側：http://192.168.3.3:3000

・API側：http://127.0.0.1:3000

カギとなるGemについて

✦ APIモードでの実装（今回の実装分）で重要なもの

実装は従来のRails開発とそれほど変わりませんが、JSONの整形やクロスドメイン対応のGemがポイントに！

★デフォルトで入っているAPI開発でカギとなるGem

・(有効化)JSON出力用のテンプレートを作成するGem　→　gem'jbuilder','~>2.5'

・(有効化)クロスドメインでのアクセスを有効にするGem　→　gem'rack-cors'

classApplication<Rails::Application・・・（省略）・・・

#Corsに関する設定を追記するconfig.middleware.insert_before0,"Rack::Cors"doallowdoorigins'*'resource'*',:headers=>:any,:methods=>[:get,:post,:options]endendconfig.api_only=trueend

config/application.rb※rack-corsの設定今回は画像のアップロードのサンプルなので、

Paperclipも使用しています。

※AWSへアップロード用のGemも一応入れました。

✦ それでは実際のAPIモードの中身とサンプルを見ていきましょう！

画面でデモを行います

※今回発表した内容に関しては後日（遅くとも10月中）にはQiitaにてまとめますので宜しくお願いします

画面にご注目ください！

✦ Railsがよりシンプルな形で扱いやすくなった感じ

今回のまとめ

ご清聴ありがとうございました！またこのような機会があった際には是非ともよろしくお願い致します！

★フロント周りのものがあまりないので実装がしやすい

機能やロジックの実装により集中しやすい構成になっているので扱いやすい

★マイクロサービスアーキテクチャの概念の理解があると良い

どうしてAPIモードがこのような形になっているかが掴める

★併せてフロントエンド部分の理解があるとより良い

機能ごとのAPIとして使用するケースが多いのでフロントエンドの理解があると実装や設計がしやすい

★自分ルール

【良いアウトプットのために】

発表・登壇時はこの中のいずれか2つを

絶対に準備するルールを設けています！