秒間 10,000 リクエストを "簡単に"いなすゲームサーバーを Laravel で作る設計
1秒間に PHP が受信する HTTP リクエストが最大 10,000 回以上——— そんな世界が存在します。その一つが 「ソーシャルゲーム」 です。メンテナンスが明けた瞬間、イベントが始まった・終わる瞬間、様々なタイミングでゲームサーバーは瞬間的に高負荷になります。もちろん、サービスをリリースし PR をたくさん出し始めたその瞬間が、プロジェクトで最も高負荷となるでしょう。それらに耐えうるサーバー構成が求められていますが、「リリース直後にサーバーがダウンした」「限定イベントが始まったらすぐ緊急メンテナンスが始まった」という話はちょくちょく聞こえてきます。その 瞬間的な高負荷(いわゆる "スパイク") に耐えるには、事前準備を怠らないことが重要です。 ソーシャルゲームにおいては、他の Web アプリケーションに比べ 書き込みヘビーなワークロード であることが多いです。読み込みは比較的簡単に
swoole と laravel-swoole を用いたハイパフォーマンスアプリケーション構築 - Speaker Deck
Speaker Deck This deck requires a password Password
5年間 Laravel を使って辿り着いた，全然頑張らない「なんちゃってクリーンアーキテクチャ」という落としどころ
この記事は Laravel Advent Calendar 2020 - Qiita 最終日の記事です。 TL;DR DDD や "真の" クリーンアーキテクチャは， Web 業界における大抵の現場ではオーバースペックだし，導入しても全員がついてこれるとは限らない app/UseCases ディレクトリだけ切って，ドメインごとに単一責務なクラスを置くと使いやすいよ ActiveRecord 指向のフレームワークで Repository パターンを無理に導入すると死ぬので， UseCase で Eloquent Model の機能を使うことを恐れるな はじめに Zenn では初投稿です。日本の Laravel コミュニティではもうお馴染みのようで実はあまり顔を出していない（？） @mpyw と申します。オンラインサロンの火付け役となった Synapse が最初の仕事でしたが，就職後すぐ会社が
PHPフレームワークLaravelの使い方 - Qiita
環境構築 ・LAMP+Redis環境を超短手数で構築する ・Composerをインストールする ・eclipseでPHPの開発環境を構築する。デバッグでブレークポイントを付けてステップ実行できるようにする 実装 ・eclipseでLaravel開発環境を構築する。デバッグでブレークポイントをつけて止める。(WindowsもVagrantもdockerも) ・Laravelのテンプレートエンジンを使う ・Laravelのレイアウトエンジンを使う ・Laravelでビュー描画前処理を行う ・Laravelでリクエストデータを取得する ・Laravelでエラーハンドリング(エラー時の制御)を行う ・Laravelでセッションを使う ・Laravelでファイルアップロード機能を実装する ・Laravelでファイルダウンロード機能を実装する ・LaravelでJSONを返す ・LaravelでJSO
最強のLaravel開発環境をDockerを使って構築する - Qiita
※Linuxはもちろんですが、Docker for Mac(M1 Mac含む), Docker for Windows で動作します。 Dockerの勉強をしたい方向け ハンズオン形式の記事を書いてるので、DockerでLaravel環境する方法を一から勉強したい人はこちらの記事がおすすめです。 【初心者向け】20分でLaravel開発環境を爆速構築するDockerハンズオン 概要 Docker, Docker Compose を使って、nginx, php-fpm, MySQLの実行環境(LEMP)を構築して、最強のLaravel開発環境を構築する記事です。 Laravelが最低限動作して、シンプルで軽量かつベストプラクティスなコンテナ、ディレクトリ構成を考えました。 最小限の構成なので、DockerイメージのビルドはLaradockより10倍以上高速にビルド完了します。 リポジトリ h
[Laravel] 機能テストで Guzzle インスタンスの通信をモックする - Qiita
【2021/10/15 追記】 現在の Laravel には組み込みの HTTP クライアントが存在するので，それを使っておくのが一番テストしやすいとは思います。しかしフレームワークロックインは発生してしまうので，依然として疎結合に保ちたい部分では Guzzle を選択する意味はあると思います。 はじめに みなさん，テストにおいて Guzzle の通信が絡む部分ってどうしていますか？ ユニットテストと機能テストで手法が異なるので，自分が採用している方法をそれぞれ紹介します。 例 通信を Guzzle に委ね， JSON をパースしてオブジェクトを生成する処理は JsonParser というクラスに委ねているクライアントのテストを考えます。 <?php namespace App\Services\Twitter; use GuzzleHttp\ClientInterface as Guzz
![[Laravel] 機能テストで Guzzle インスタンスの通信をモックする - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/8c14e2e55a2af782a7c2400bab156e85c6273b22/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCTGFyYXZlbCU1RCUyMCVFNiVBOSU5RiVFOCU4MyVCRCVFMyU4MyU4NiVFMyU4MiVCOSVFMyU4MyU4OCVFMyU4MSVBNyUyMEd1enpsZSUyMCVFMyU4MiVBNCVFMyU4MyVCMyVFMyU4MiVCOSVFMyU4MiVCRiVFMyU4MyVCMyVFMyU4MiVCOSVFMyU4MSVBRSVFOSU4MCU5QSVFNCVCRiVBMSVFMyU4MiU5MiVFMyU4MyVBMiVFMyU4MyU4MyVFMyU4MiVBRiVFMyU4MSU5OSVFMyU4MiU4QiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnM9ODBhODNlZjdkNmFhYjkzOTkwMDE4OTMyYjRkN2ZlMjM%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBtcHl3JnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz05YWI3NzllNDFiNDU0ODg3NzdmYTFhYmQ2ZDA3MzIzYQ%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3D56346eb5796b852b4cde25d7a2078b8a)
【初心者向け】Laravel Policyの使い方(認可) - Qiita
はじめに あなたは何かWebアプリケーションを作っているとします。 このWebアプリではItemというモデルを取り扱っていて、複数のItemを一覧で見る画面や、個々のItemの詳細を見る画面があります。 /itemsにアクセスしたらItemの一覧画面が表示されて、items/1やitems/2にアクセスしたら、それぞれのidのItem詳細画面が表示されます。 各モデルに所有者がいたとして さて、このItemですが、それぞれに所有者が存在するとします。 idが1であるItemの所有者はAさん、idが2であるItemの所有者はBさん・・・といった具合です。 AさんもBさんもこのWebアプリにユーザーとしてログインできるのですが、全てのItemを見ることはできなくて自分の所有するItemだけを見ることができる、という要件があなたが作るWebアプリに求められているとします。 その為に何をする必要が
Laravel の Guard（認証） って実際何をやっているのじゃ？ - Qiita
ルートで middleware を呼ぶと、指定した Guard で 認証されたユーザーだけにアクセス許可 します🔑 Guard クラスはどうやって呼び出すのじゃ？ 'driver' => 'session' のように、 session / token 等の Guardクラス の driver を指定します。 独自の カスタム Guard やパッケージで追加した Guard を指定することも可能です。 driver って何なのじゃ？ Guard に付けられた名前ぐらいに思っておけば大丈夫そうです。 カスタムGuard の場合は、 Guard インスタンスを返すクロージャでした！ （詳しくは↓ カスタム Guard はどうやって登録されるのじゃ？ 参照） カスタム Guard はどうやって登録されるのじゃ？ カスタム Guard を登録するには、ドライバ名と Guard （を継承・実装した）
LaravelとSchemaSpyで簡単ER図作成 - Qiita
ER図を描こう あるwebサービスの運用を他のチームに引き継ぐことになりまして、 ふとデータベースまわりのドキュメントがないことに気づきました。 とまあ、そんな状況でなくともER図を描くのは面倒です。 構築したテーブルから生成 統合環境等で作成もできますが、外部キーを張っていないと自動生成できません。 運用していたwebサービスは外部キーは張っていなくてアプリケーションでリレーションをしていたので、テーブルとカラムのリストまでしか読み込めません。 かといって専用のツールで描くと、MacとWindowsで共有できないことがありますし Excelで作成するのはちょっと。。 SchemaSpyというツールを使いました。 これだと、DBから読み取れるところは読み取って、 追加でリレーションやカラムコメントを記述することができます。 [https://schemaspy.readthedocs.io
Laravelで実践クリーンアーキテクチャ - Qiita
この記事を書くにあたって Laravel について色々サポートしてくれた皆さまに向けてお礼申し上げます。ありがとうございました。 本記事はクリーンアーキテクチャに対する理解を深めていただくために、「実践クリーンアーキテクチャ」の内容を Laravel で実装して解説するという内容になっています。 記事のゴールは「クリーンアーキテクチャに対する理解を深めてもらう」というものです。つまり、この実装の形は一例に過ぎません。 はじめに 皆さんクリーンアーキテクチャはご存知でしょうか。 そう、こんな図のアレです。 The Clean Architecture: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html クリーンアーキテクチャといえばこちらの象徴的な図をまずは思い浮かべるでしょう。 この図を
Laravelの実装調査 ～会員登録編・署名付きリンクもあるよ～ - Qiita
仕事でやや変則的な認証処理を作る事になったので、Laravelでスキャッフォルドされる会員登録周りの実装がどうなっているのかを調べてみました。 該当箇所のコードを引用しつつ、コメントを付与する形で解説しています。 なお、会員登録周りをカスタマイズする方法を解説している記事ではないので注意してください。 あくまでLaravel内部でどういう処理が行われているのかを調べた記事になります。 調査に使用したLaravelのバージョンは5.7.22です。 関連記事 Laravelの実装調査 ～ログイン編・リメンバーログインもあるよ～ Laravelの実装調査 ～パスワードリセット編～ 今回は会員登録編という事で、以下２ケースをまとめています。 会員登録 メールアドレス確認 それでは見ていきましょう。
【Laravel】 通知に関する補足と拡張の手引き - Qiita
はじめに まずはマニュアルの一読を。 通知 5.7 Laravel 基本的に Laravel のコンポーネントは完成度が高く，あまり自分で拡張する必要は無いが，「通知」に限っては機能拡張しないと実用性に乏しい面が多い。そのため，拡張すべきところとその実装例も一部示していくことにする。 なお通知機能は Laravel の他の基礎機能の上に構築されているため，それらに対する理解も必要だ。以下に関連する記事を示しておく。 【Laravel】サービスコンテナ・サービスプロバイダ・ファサード・契約に関する補足資料 - Qiita 【Laravel】 キュー・イベント・ブロードキャストに関する補足とフロントエンドへの導入 - Qiita 通知のアーキテクチャ 全体の概要図を示す。通知の送信手段としては メール送信 ブロードキャスト送信 データベースレコード作成 などがあるが，ここでは例としてデータベー
【Laravel】 キュー・イベント・ブロードキャストに関する補足とフロントエンドへの導入 - Qiita
コネクションは複数のキューを持つことができる。一般的に，ジョブの種類や優先度によってキューを分岐することが多い。 キューとワーカーは一対一で対応するとは限らず，「どのワーカーがどのキューを処理するか」ということに関して任意の組み合わせが可能である。 総称として，バスを除くこれらの仕組みをまとめて「キュー」と呼ぶこともある。 ジョブのアーキテクチャ ジョブをディスパッチする方法 マニュアルには // このジョブはデフォルトキューへ送られる Job::dispatch(); // このジョブは"emails"キューへ送られる Job::dispatch()->onQueue('emails'); <?php namespace Illuminate\Foundation\Bus; use Illuminate\Contracts\Bus\Dispatcher; class PendingDis
【Laravel】 認証や認可に関する補足資料 - Qiita
アプリケーション例外は Laravel フレームワークで定義されているもので，HTTPに直接関係ない抽象的な部分ではまずこれをスローすべき。 HTTP 例外は Symfony フレームワークで定義されているもので，Handler::render() でアプリケーション例外から変換して生成するのが一般的。 401 Unauthenticated のほうがどう考えても正しいが，そうなってないのには歴史的な理由があるのだろうか…？ 認証のアーキテクチャ Auth ファサードあるいはコンテナから "auth" のエイリアス名でアクセスできる，認証サービスのルートオブジェクトが AuthManager である。ここが認証サービスの中核となる。 Guard が認証手段ごとの実装として存在し，ロジックの多くはここに集約される。 このクラスは Guard 契約 を実装しなければならない。 ユーザを取得して
Deep Dive into Laravel Eloquent ORM - Qiita
はじめに 過去にLaravel（5.6）のリクエストライフサイクルを中心にご紹介しました。 Deep Dive into Laravel 今回はEloquentの基本動作とリレーションについてご紹介したいと思います。その他のコレクションやミューテタなどの機能はここでは触れませんので公式サイトをご覧ください。 [公式サイト]Eloquent https://laravel.com/docs/5.6/eloquent 処理の流れ Eloquentの仕組みを見るために、まずは簡単なCRUD操作を例に基本的な内部処理の流れを見てみたいと思います。 Read 以下のようなモデルからデータを取得する処理の流れを順番に見てみます。 処理の流れを簡略化したものが以下のようになります（実際はもう少し複雑ですが分かりやすくするために省略しています）。 まず、アプリケーションモデルが継承する基底ModelがEl
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【Laravel】Docker for WindowsでLaradock(+MySQL)の環境構築 - Qiita
GitHub - alexeymezenin/laravel-best-practices: Laravel best practices
GitHub - mikebronner/laravel-sign-in-with-apple: Provide "Sign In With Apple" functionality to your Laravel app.