Larvel jp

2019/02/16 東京

ふらっと久しぶりに出張ったので。

Service Provider & Service Container

前田さん

サービスコンテナー気になる人向け

ServiceConterner

サービス・自動注入・DI・サービスコンテナ・インターフェースの複合物。今回は DI/サービスコンテナに絞って。

DI

例:

SendGrid にコンタクトリストにユーザを追加する
SendGridを使ってメールを送信する

ユースケース: ユーザ側と管理者側でAPIキーを分けることに。

$this->service = new \SendGrid(config('services.sendgrid.key'));

これをどうする？

案:

UserSendGrid?AdminSendGrid? -> まぁ増えたらしんどいよね
getter/setter -> インスタンス管理がねー
DIかな？

Di = インスタンスの生成に必要な設定をコンストラクタの引数で渡してあげること。

今回は \SendGrid(config('services.sendgrid.key')) 部分をDIに。

class SendGridService{

    public function __construct(SendGrid $sendgrid){
        $this->service = $sendgrid;
    }
}

...

$service = new SendGridService(.new \SendGrid(config('services.sendgrid.key')) );

-> これの問題点

これだと、サービス作る時に new するのでしんどいよね。
設定やらが増えたら？

サービスコンテナ

各処理ごとに毎回作る：サービスコンテナ

こんな漢字

$conteinr = [
    'sendgrid' => SendGridService::class,
    ...
];

どこからでも呼べる。 resolv('sendgrid') ←これ。 app() との違いは…？

サービスプロバイダ

サービスプロバイダ: サービスの精製方法をまとめて管理

registerメソッドを使ってデータを登録。AppServiceProvider のあれ。サービスごとに別けて、app.php に登録したほうが良いよ。

class sendGridServiceProvider extends ServiceProvider {
    public function register(){
        $this->app->bind('sendgird', function($app){
            $sendgird = new SendGrid(config('services.sendgrid.key'));
            return new SendGridService($sendgird);
        });
    }
}

...

$service = resolve('sendgrid');

まとめ

今回は DI の話。

ちょっとした感想

多分ここらへんだけで、テストの話までなるから、どっかで一通りは聞いてみたいなーなー

Larvel Package 管理

みかかねさん

laravel-package の話。

see: https://speakerdeck.com/mikakane/laravel-package-development

Laravel の機能が使える。

app フォルダーをスリムにして、見やすくする。

Routing loadROuteFrom(__DIR__.'/routes/api.php') みたいな形で使える

Migration loadMigrationsFrom(__DIR__.'/path/to/migrations') みたいな。昔はvendorでやってたよね。

View loadViewsFrom(__DIR__.'/views/') みたいな

Vendor.publish : 使う側にファイル展開

composer.json に extra section を追加すりゃ使えるよ。(確か Laravel 5.5以降よな)

Package 管理面倒じゃね？

tagやらversionやら…

-> 気軽に始めるには？

psr-4 の app 以外に書き換えて、ええようにやっていく。

Type Path Repository => ？

親の composer.json に書くアレ

{
    'repositories' : [
        {'type': 'path', 'url': './modules/function1'}
    ]
}

依存関係のパッケージインストールはこんな感じ

$ composer require chatbox-inc/mailsystem:*@dev

APP しかできないこと

exception handler
service provider 管理
などなど

RDB

そーだいさん。hateblog に置いてる。

よくある話

ユーザが増えて重くなった
バッチが突き抜けた

開発速度と実行速度は同じぐらい大事 => だいたいは RDB が重かったりする。

今日は RDBS 限定の話。

婚活といえばオミカレですよー

クライアント　→　パーサ・リラいた　→　プランな・オプティマイザ　→　エグゼキュータ　→　データ

だいたいはエグゼキュータが遅い　→　RDBMS が苦手な処理をしている　→　リレーショナルモデルになっていない

履歴・ツリー型はRDBMS の苦手。

Explain 文で見る。MySQLは5.7？から DELETE/INsert 文にも使える。

活用できてない

index 使ってない
不要な大きなデータを使ってる

1. インプリシットカラムの例（SQLアンチパターン）
2. where で小さくする
3. from区で小さくる
3. 不要なjoinをなくす

=> ORM/QueryBuilderが実行するクエリを知ることが大事

テーブル設計が悪い => 積み木。マジカルな初期設計だと死ぬ -> RDBMS に適した設計が必要

Index が使えないパターン

検索結果が多い・全体の件数が少ない
条件にその列を使ってない
カーディナリティの低い列に対する検索（A/B だけの時にAが極端に多いのを、カーディナリティが低い）
あいまい検索
統計情報と実際のテーブルで乖離がある場合

sql-performance-experience.com ?

などなど

Framework 依存症

foreing-key がねーよなどなど

絶対悪ではない。フレームワークに依存しない最適な設計を常に模索

Laravel デプロイ戦略

鶴島さん

speaker deck にあるっぽい。

Deployを考えなくていい状態がいいよね。

一番言いたい所：永続データ以外は廃棄しよう

PaaS => 乗っけられるかどうか見極め大事。無理だったら泥沼。

Docker Managed => Scale楽よ。

NFS は意外と重い。
aws だと code pipeline を始めに検討　-> gitlab, jenkins もあるよ
docker/fargate
session などは dynamodb

config : .env 使おう
file storage : s3 に。IAMの設定はしっかりね。
session : redis/memcached を使おう. dynamodb もオンデマンドキャパシティ使えばいいよ。
db : read/write 別けられる
queue : メール送信とか。
task scheduling : 意外と大変。schedule から Queueで動かすとか。

Docker : Laravel のソースが入っているコンテナを作ったほうが意外といい。開発は docker-composer up がいいよ。

ENTRY_POINT を使うと、PHP.iniの設定変えられるよ。

IAM の Role を？

ストレージの初期設定は、初期しかできないので。

Dockerの脆弱性スキャナを。

TImezone : よく忘れてるよ。
メール：外部サービス
ログ：なにかあると求められる。機密情報はログに入れないように。

stackdriver logging

例外ハンドラ : rollbar で。

Laravel職人もDocker職人に。

かんそー

個人的に一番欲しいなーというものなので、ありがたやありがたや。

laravel JP conference 19 memo