Rails Wayの再考

~ Laravel や gRPCを使ってみてRails Wayを振り返る~

@saboyutaka

2018/07/14

RailsDM 2018 Extreme

自己紹介

• さぼ、@saboyutaka (立花 豊)
• 福岡 -> 東京 -> 沖縄
• フリーランス/フルリモート/Webエンジニア
• Rails/Laravel/gRPC(Go)/AWS/Azure
• Ruby/PHP/Go/Python/JavaScript
• 最近、Microservices, k8sなんかに興味あります
• Okinawa.rb から来ました

自己紹介

• Rails歴 6年(2012年~)
• もともとPHPは一生かかない言語と生存戦略的に考えてた
• この2年くらい、Laravel, Go, Pythonなど複数言語を扱うようになった

​

きっかけ

https://twitter.com/kamipo/status/987268595510996992

Laravelの紹介

Laravel

Laravel

• The PHP Framework for Web Artisan
• 2011年~
• PHP製のフルスタックWeb Framework

​

Google トレンド RoR vs Laravel

Google トレンド RoR vs Laravel

Google トレンド RoR vs Laravel

Google トレンド Ruby vs PHP

Google トレンド Ruby vs PHP

Google トレンド Ruby vs PHP

Google トレンド RoR vs Laravel

Github Stars

Laravelの特徴

• 参考にしたフレームワークとして.Net, Sinatra, Rails
• 根底のクラス郡はSymfonyを利用
• 設計が綺麗
• 超フルスタック
• 創始者のTylor Otwellが7年以上フルタイムでずっと作り続けてる
• ドキュメント、フォーラム、動画などの整備がすごい

​

超フルスタック(Railsに比べて)

https://laravel.com/docs/5.6

超フルスタック(Railsに比べて)

https://readouble.com/laravel/5.6/ja

Laravelのコードサンプル

• https://github.com/guillaumebriday/laravel-blog

RoR と Laravel の比較

Taylor Otwell

Taylor Otwellのここがすごい

• ほぼ一人でLaravelを作ってる(去年2人になった)
• 7年間フルタイムでLaravelについての仕事してる
• ドキュメントも書いてる
• フォーラムも作った
• 流行らせるために書籍も書いた
• カンファレンスにも結構参加してる

Laravelの良いところ(個人的に)

• ドキュメント、フォーラム、学習用の動画が用意されている
• 初めて入ってきた人がキャッチアップしやすい仕組みをちゃんと作っている
• 何かの統計で、ドキュメントの整備状況とソフトウェアが流行る事には相関があるらしい
• 設計が綺麗
• 基礎概念のコンポーネントですべて?の機能が実装されてる
• ServiceProvider, ServiceContainer, Facade, Middleware
• php.netとLaravel docsとフォーラムでほぼ全ての情報が揃う
• PHP7, IDEの相性が良い
• 型指定ができるようになって定義元ジャンプがほぼほぼ完璧に出来る

​

Laravelの良いところ(個人的に)

• 各コンポーネントが疎結合に実装出来るように考慮されているのでパーツを差し替え可能
• ORMをEloquentから、DDDなライブラリに変えても良い(Doctorinとか？
• フロントエンドとサーバーサイド実装も割と疎結合
• Assetsコンパイル周り(Laravel Mix)が完全にNode.jsに委譲していて良い

​

Laravelの印象(個人的に)

• Railsは先駆者、Laravelは遅れてきた期待の新人
• 他のWAFのGood Partsを効率よく丁寧に実装している
• いい感じに抽象化されたコンポーネント郡
• JavaのかっちりさとRubyの柔軟さのハイブリットみたいな印象
• 覚える要素はRailsのコアに比べては多いので初心者がいきなり入るとむずかしそう

Laravelは銀の弾丸なのか

• もちろんそうじゃない
• Railsと同じくMonolithic Application Pattern、つらくなるところも似てる
• DIしすぎると無駄に複雑化する
• 大きくなるとどんどんJava化していく
• Railsと書き味が似ている
• ActiveRecord Pattern ORM
• Rapid Prototyping
• RailsエンジニアがPHPを書く必要性が出てきたら低学習コストで書けるWAFが出来た
• フロントエンド周りの扱いは上手
• Laravel Mix

​

RailsをやめてLaravelに行ったほうがいいのか？

移行したほうが良い！というほどでもない

ただ

Railsにも古くなってるパーツはある

(周回遅れと言われる要因？)

Railsの古くなったパーツ

• 特にフロントエンド周り
• AssetsPipeline
• CoffeeScript
• Turbolinks
• Rails 3.1 で導入された(2011/08/31)
• 当時はAssetsPipelineのBetterな方法がなく画期的なしくみだった
• ES5しかない時代はCoffeeScriptで解決される問題があった

​

2018年現在のフロントエンド

• ES2015(ES6)~やTypeScriptで書く
• Build Tool
• Webpack, percel, Rollup
• React.js, Vue.js, AngulerJS
• npm, yarn

Webpacker

• https://github.com/rails/webpacker
• RailsでWebpackを使うためのAPI
• RubyのRuntimeで動く...
• 設定がWebpacker特有で学習コストが高い
• ディレクトリ構造....
• .js.erbとかやりがち
• AssetsPipelineとのハイブリットとかやりがち
• フロントエンドエンジニアが理解できない

Laravel Mix

Laravel Mix

• https://github.com/JeffreyWay/laravel-mix
• Laravel の Assets Compile の機能
• WebpackのWrapper API
• Node.jsのライブラリ、PHP全く関係ない
• Laravelの新プロジェクト作ったそばからes6, Vue.js, SCSS書ける
• Laravelじゃなくても使える

Laravel Mix

• Node.jsだけで動く、PHP全く関係ない
• Assets作るだけだとNodeのruntimeだけで動く
• Docker Container作る時にコンテナを小さく作れる
• フロントエンドのみの開発環境を提供しやすい
• デザイナー、フロントエンドエンジニアとの共同作業の悩みをLaravel Mixで解決する
• https://qiita.com/saboyutaka/items/f5793a1c3dc25b4a9305

これRailsでも使えたら便利じゃん

やってみた

https://github.com/saboyutaka/rails-laravel-mix

便利そう

Monolithic Application Pattern

Monolithic Application Pattern

http://microservices.io/patterns/monolithic.html

Monolithic Application Pattern

• プロジェクトの生産性の初速は高い
• Simple {Development|Deploy|Test|Scale}

​

http://microservices.io/patterns/monolithic.html

Monolithic Application Patternの問題点

• ある程度プロダクトが成熟したら
• 生産性が落ちる
• コードを読むのが大変
• IDEが重くなる
• 立ち上げるのに時間がかかる
• サービスの一部だけのスケールが難しい
• 依存関係が複雑で技術的負債を返すコストが高い

​

• ​
• Simple {Development|Deploy|Test|Scale}

​

http://microservices.io/patterns/monolithic.html

Rails も Laravel も

• Monolithic Application Patternなので
• Railsが良い/悪い、Laravelが良い/悪いというよりもMonolithに限界がある
• この点はどちらも一緒

http://microservices.io/patterns/monolithic.html

なぜ Monolithが選択されてきたか

• 今まではマルチプロセスの管理、デプロイを行う運用コストが高かった
• シングルプロセス、シングルDBが基本
• 必然的にMonolithが妥当

​

Microservicesとクラウドデザインパターン

​

Microservices

• コンテナ技術(Docker)が当たり前になってきた
• Kubernetes元年
• gRPC
• Cloud Native
• クラウドデザインパターン

Microservices(Service Mesh)

http://philcalcado.com/2017/08/03/pattern_service_mesh.html

Docker & Kubernetes(k8s)

Cloud Design Patterns

https://docs.microsoft.com/ja-jp/azure/architecture/patterns/

マルチコンテナ

• Docker, docker-compose, Kubernetesでマルチプロセス立てるのが楽になってきた
• AWSのサービスはlocalstackとしてDockerイメージが公開されてる

​

マルチコンテナ以降のWebサービス開発

• 最初はMonolithicに作る
• ある程度成熟するとMicroservices化していく
• 最初からCloud Nativeな設計をする
• クラウドデザインパターンを適用して、適材適所でサービスを利用する
• 複数のコンテナを利用して小さなサービス群を作るように設計を進める
• 複数DB前提
• メインのアプリケーション(Railsとか)の責務を減らす
• コアロジックのみ載せるとか？

将来Microservices化、または言語以降するために今出来ること

• フロントエンドをRailsっぽく書かない
• Webpack, Laravel Mix などを使う。AssetsPipelineやめる
• View Helperを使わない
• View Helperって実際生産性上がってます？
• ERB使う
• 多言語でApplication書くとHTMLに近い方が生産性、可読性が高かった
• できるだけサービス層を切り分けて実装する
• 将来Microservice化したらどうなるかを想像しながらサービス分離する

将来Microservices化、または言語以降するために今出来ること

• フロントエンドをRailsっぽく書かない
• Webpack, Laravel Mix などを使う。AssetsPipelineやめる
• View Helperを使わない
• View Helperって実際生産性上がってます？
• ERB使う
• 多言語でApplication書くとHTMLに近い方が生産性、可読性が高かった
• できるだけサービス層を切り分けて実装する
• 将来Microservice化したらどうなるかを想像しながらサービス分離する

言語とコミュニティ

PHPのコミュニティ

• Laravelを初めて作った時にPHPコミュニティの人に受け入れてもらえなかった
• くやしくて彼らの期待を超えるものを作ると決めた
• その後Laravelがある程度成熟したが、避難する人は避難をやめなかった
• 批判する人の声を聞くのをやめ、自分やLaravelを愛してくれるひとのためにコードを書くことにした

https://medium.com/@taylorotwell/community-hoops-37bd3633114

Rubyのコミュニティ

• やり方が複数あっても良いというRubyの言語思想
• gemでプラグイン形式で作る
• コミュニティで作ってコミュニティで育てる
• みんな(だいたい) Railsを使っている
• コミュニティに参加してる人がコミュニティを大切にする意識が高い

​

みんなで作るRails

みんなで作るRails

• Railsが周回遅れになるかどうかはコミュニティの参加度合い、利用度合い次第
• Railsで仕事していくためにRails、Rubyに参加する

​

まとめ

まとめ

• RailsもLaravelもだいたい同じように書ける。Railsは一部古くなってるパーツがあるのでそれは避ける
• MonolithがつらくなるタイミングでMicroservice化していく必要がある、そのため予めクラウドデザインパターンを利用して疎結合に設計する
• Ruby, Railsをより良いものにしていくためにみんなで参加する

​

ご清聴ありがとうございました🙏

Rails Wayの再考

~ Laravel や gRPCを使ってみてRails Wayを振り返る~

@saboyutaka