Laravel – エンジニア見習い https://otonan-syusyoku.work 三流プログラマー Tue, 06 Jan 2026 07:22:32 +0000 ja hourly 1 https://wordpress.org/?v=6.9.4 https://otonan-syusyoku.work/wp-content/uploads/2023/10/cropped-名称未設定のデザイン-16-32x32.png Laravel – エンジニア見習い https://otonan-syusyoku.work 32 32 Laravel+Inertia+ReactをECSで動かしたい！ NginxとPHP-FPMのコンテナ分離 https://otonan-syusyoku.work/archives/2153 https://otonan-syusyoku.work/archives/2153#respond Tue, 28 Oct 2025 05:24:52 +0000 https://otonan-syusyoku.work/?p=2153 Laravel + Inertia (React/Vue) の組み合わせは、SPA（シングルページアプリケーション）の体験とサーバーサイド（Laravel）の書きやすさを両立できる、非常に強力な構成です。

しかし、ローカルのDocker Compose環境では問題なく動作しても、AWSのECS Fargateのような本番環境にデプロイしようとすると、いくつかの疑問に直面します。

  • 「NginxとPHP-FPMコンテナはどう連携させるのがベスト？」
  • 「fastcgi_pass ってローカルと設定を変える必要ある？」
  • 「InertiaでビルドしたReactのJS/CSSファイルは、結局どのコンテナに置くのが正解？」

この記事では、fastcgi_pass の基本から、ECS Fargateでの最適なコンテナ構成、そしてInertia/Reactプロジェクト特有の「静的ファイルの配置場所」問題までを、順を追って解説します。

fastcgi_pass とは？

NginxとPHP-FPMの「橋渡し」

まず基本のおさらいです。Nginxは高性能なWebサーバーですが、それ自体はPHPコードを実行できません。
一方、PHP-FPMはPHPコードを実行することに特化したプロセス（サーバー）です。

Nginxがクライアント（ブラウザ）から .php ファイルへのリクエストを受け取ったとき、そのリクエストをPHP-FPMに処理してもらう必要があります。

このとき、Nginxの設定ファイル（nginx.conf）で、「どのPHP-FPMに処理を依頼するか」の宛先を指定するのが fastcgi_pass ディレクティブです。

location ~ \.php$ {
    # ...
    # ↓ この一行が「橋渡し」の指定
    fastcgi_pass php-fpm-server:9000; 
}

 

ローカル開発 (Docker Compose) での構成

ローカル開発では、「1コンテナ1責務」の原則に従い、NginxとPHP-FPMを別々のコンテナとして docker-compose.yml で定義するのが一般的です。

# docker-compose.yml (抜粋)
version: '3'
services:
  # Nginxコンテナ
  nginx:
    image: nginx:alpine
    ports:
      - "80:80"
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf
      - ./laravel-project:/var/www/html

  # PHP-FPMコンテナ
  php:
    build: . # PHP-FPMとLaravelコードを含むDockerfile
    volumes:
      - ./laravel-project:/var/www/html

 

この構成では、NginxコンテナとPHPコンテナは 別々のネットワーク空間 に存在します。Docker Composeが提供する内部ネットワークを介して、サービス名で通信します。

したがって、NginxコンテナからPHPコンテナへは、php というサービス名（ホスト名）を使ってアクセスします。

# nginx.conf (Docker Compose用)
location ~ \.php$ {
    # ...
    # 'php' サービス（コンテナ）の 9000番ポートに転送
    fastcgi_pass php:9000;
}

 

（※ このTCP/IP通信によるパフォーマンスやセキュリティの懸念は、コンテナ間通信がDockerの内部ネットワークに限定されていれば、実用上ほとんど問題になりません。）

【1タスク2コンテナ】本番 (ECS Fargate) での構成：

さて、本題のECS Fargateです。
ECSでは、docker-compose.yml に相当するものとして「タスク定義 (Task Definition)」を使います。

ここで重要なキーポイントは、「1つのタスク定義の中で、NginxコンテナとPHP-FPMコンテナの2つを定義する」ことです。

これら2つのコンテナは、1セットで「Webアプリケーションサーバー」として機能します。

ECS Fargateでのfastcgi_passはどうなる？

ECSの同一タスク内で実行されるコンテナは、同じネットワーク空間（ネットワークモード awsvpc）を共有します。

これは、Nginxコンテナから見ると、PHP-FPMコンテナが「他人」ではなく、「自分自身（localhost）」として見えることを意味します。

したがって、ECS Fargate用のNginxイメージに含める nginx.conf の設定は、以下のようになります。

# nginx.conf (ECS Fargate用)
location ~ \.php$ {
    # ...
    # サービス名ではなく、localhost (127.0.0.1) を指定する
    fastcgi_pass 127.0.0.1:9000;
}

 

タスク定義のイメージ

タスク定義では、以下のように設定します。

  • コンテナ-A: php-fpm-container
    • イメージ: （Laravelコードを含むPHP-FPMイメージ）
    • ポートマッピング: なし (外部に公開する必要はないため)
  • コンテナ-B: nginx-container
    • イメージ: （設定済みのnginx.confと静的ファイルを含むNginxイメージ）
    • ポートマッピング: 80:80 (ALBからのトラフィックを受け取るため)

ALB（ロードバランサー）からのトラフィックはNginxコンテナが受け取り、必要に応じて localhost:9000 を介してPHP-FPMコンテナに処理を渡します。

Inertia/Reactのビルドファイルはどこに置く？

ここで、Inertia/React構成特有の問題に直面します。

「InertiaはLaravel（PHP）がビューを配信する仕組みだから、npm run build で生成された public/build フォルダは、PHP-FPMコンテナにだけ置けば良いのでは？」

これはよくある誤解ですが、パフォーマンスと責務分離の観点から、ビルドした静的ファイル（JS/CSS）はNginxコンテナに配置するのが正解です。

この理由を理解するために、Inertiaのページが読み込まれる2段階のフローを見てみましょう。

ステップ1: HTMLシェルのリクエスト (PHP-FPMが処理)

  1. ブラウザが https://example.com/dashboard にアクセスします。
  2. ALB → Nginxコンテナがリクエストを受け取ります。
  3. NginxはこれがPHPのリクエストだと判断し、fastcgi_pass 127.0.0.1:9000 を使ってPHP-FPMコンテナに転送します。
  4. PHP (Laravel) が起動し、Inertiaは app.blade.php をレンダリングしようとします。
  5. このとき、PHPは public/build/manifest.json を読み取り、HTMLに含めるべきJS/CSSのファイル名を特定します。
  6. PHPは以下のようなHTMLの「ガワ」を生成し、Nginx経由でブラウザに返します。 

    <html>
<head>
    <script src="/build/assets/app.12345.js" defer></script>
    <link rel="stylesheet" href="/build/assets/app.67890.css">
</head>
<body>
    <div id="app" data-page="..."></div>
</body>
</html>

ステップ2: 静的アセット(JS/CSS)のリクエスト (Nginxが処理)

  1. ブラウザは、ステップ1で受け取ったHTMLを解析します。
  2. 「/build/assets/app.12345.js と /build/assets/app.67890.css が必要だ」と判断し、ブラウザは別途2回のリクエストをサーバーに送信します。
  3. このリクエストは、もはやPHPとは全く関係ありません。
  4. ALB → Nginxコンテナがこの2つのリクエストを受け取ります。
  5. Nginxは「自分の管理下（public フォルダ）にそのファイルがあるか？」を探します。
  6. Nginxコンテナに public/build/ 以下の実体ファイルが存在するため、NginxはPHP-FPMを起動することなく、それらの静的ファイルを超高速でブラウザに直接返します。

もし、NginxコンテナにJS/CSSファイルがなければ、このリクエストもPHP-FPMに転送されてしまい、「JSファイルを取得するためだけにLaravelを起動する」という深刻なパフォーマンスボトルネックが発生します。

CI/CDでのベストプラクティス

上記2ステップから、CI/CDパイプラインでDockerイメージをビルドする際は、以下の構成が最適です。

  1. npm run build を実行し、public/build ディレクトリを生成します。
  2. PHP-FPMイメージのビルド:
    • Laravelのコード（app/, routes/ など）をコピーします。
    • ステップ1のために public/build/manifest.json をコピーします。（リンク生成に必要）
  3. Nginxイメージのビルド:
    • nginx.conf をコピーします。
    • ステップ2のために public フォルダ全体（index.php と、public/build 以下の 全てのJS/CSSファイル を含む）をコピーします。（静的アセットの配信用）

結論

manifest.json はPHP-FPMコンテナに、JS/CSSの実体ファイルはNginxコンテナに必要です。

両方のイメージに public フォルダ（または public/build）全体をコピーするのが、最もシンプルで確実な方法です。

まとめ

ECS Fargateで Laravel + Inertia + React 構成を動かすための要点をまとめます。

  1. 構成: 「1タスク2コンテナ（Nginx + PHP-FPM）」構成を採用します。
  2. fastcgi_pass: NginxからPHP-FPMへの通信は、同一タスク内のため fastcgi_pass 127.0.0.1:9000; を指定します。
  3. 静的ファイル: ビルドしたJS/CSSは、パフォーマンス最適化のためNginxコンテナに配置し、Nginxから直接配信させます。
  4. manifest.json: HTMLシェル生成のため、PHP-FPMコンテナにも manifest.json が必要です。

この構成により、PHP-FPMは動的処理に専念し、Nginxは静的ファイルの高速配信に専念するという、「1コンテナ1責務」のメリットを最大限に活かした、スケーラブルな本番環境を構築できます。

]]> https://otonan-syusyoku.work/archives/2153/feed 0 Nginxの「upstream sent too big header」エラーを解決する：LaravelとPHP-FPM環境での対処法 https://otonan-syusyoku.work/archives/2128 https://otonan-syusyoku.work/archives/2128#respond Mon, 23 Jun 2025 15:04:51 +0000 https://otonan-syusyoku.work/?p=2128 環境

Ubuntu：24.04
PHP：8.2
Laravel：11.x

起こったこと

NginxをWebサーバーとして、LaravelアプリケーションとPHP-FPMを連携させている環境で、ある日突然 upstream sent too big header while reading response header from upstream というエラーがNginxのエラーログに表示され、Webサイトが正常に表示されなくなリマした…

調べていくと、このエラーは、PHP-FPM（アップストリームサーバー）がNginxに返そうとしたHTTPレスポンスヘッダーのサイズが、Nginxが受け入れられる設定値の上限を超えてしまった場合に発生します。

特にLaravelのような動的なアプリケーションでは、セッション情報やクッキーの肥大化が原因で発生しやすい問題とのことでやんす。

エラーが起きる原因は？

NginxがWebサーバーとしてクライアントからのリクエストを受け取り、それをバックエンドのPHP-FPM（FastCGIプロセス）に渡して処理してもらいます。

PHP-FPMが処理を終えてNginxに応答を返す際、そのHTTPレスポンスにはヘッダー情報が含まれます。このヘッダー情報がNginxが設定しているバッファのサイズを超えると、エラーが発生してしまいます。

主な原因として、以下のようなものが挙げられます。

  • セッションデータの肥大化: Laravelなどのフレームワークでセッションをクッキーベースで管理している場合、ユーザーが多くの情報をセッションに保存したり、ショッピングカートに大量のアイテムを追加したりすると、クッキーのサイズが大きくなります。この大きなクッキー情報がレスポンスヘッダーに含まれることで、上限を超えてしまうことがあります。
  • 多数のクッキーやカスタムヘッダー: アプリケーションが非常に多くのクッキーを設定している、または独自のカスタムヘッダーを大量に追加している場合も、ヘッダー全体のサイズが大きくなります。
  • リダイレクトループ: 不適切なリダイレクト設定により、ブラウザが何度もリダイレクトを繰り返す際、そのたびに新しいクッキーやヘッダーが付与され、最終的にヘッダーが大きくなってしまうケースも考えられます。

解決策：Nginxの設定を調整する

最も手軽で直接的な解決策は、Nginxが受け入れられるヘッダーバッファのサイズを増やすことです。

Nginxの設定ファイル（通常は /etc/nginx/nginx.conf か、サイト固有の .conf ファイル）を開き、http ブロック内、または対象の server ブロック内に以下のディレクティブを追加または調整します。http ブロックに記述すると、すべてのバーチャルホストに適用されます。

http {
    # ... 他の http ブロック内の設定 ...

    # upstream sent too big header エラー対策
    # PHP-FPM（FastCGI）からのレスポンスヘッダーに対応するため、fastcgi_ のディレクティブを設定します。
    # 必要に応じて proxy_ のディレクティブも設定しますが、PHP-FPMの場合はfastcgi_を優先します。
    fastcgi_buffer_size 128k;   # FastCGIヘッダーバッファの初期サイズ。デフォルトは4k/8k。
    fastcgi_buffers     4 256k; # 256KBのバッファを4つ用意。合計1MB。

    # 必要に応じて、もしプロキシとして使用している場合も考慮するなら、こちらも設定
    # proxy_buffer_size   128k;
    # proxy_buffers       4 256k;
    # proxy_busy_buffers_size 256k;

    # ... 他の http ブロック内の設定 ...
}

 

ディレクティブの解説

  • fastcgi_buffer_size: NginxがFastCGIからのレスポンスヘッダーを読み込むための最初のバッファサイズを指定します。デフォルト値（通常は 4k または 8k）よりも大きな値（例：128k）を設定することで、大きなヘッダーにも対応できるようになります。
  • fastcgi_buffers: ヘッダーを含むレスポンス全体をバッファリングするためのバッファの数とサイズを設定します。上記の例では、256KBのバッファを4つ使用し、合計で1MBのバッファスペースを確保します。

注意点: これらの値を必要以上に大きくしすぎると、Nginxが使用するメモリ量が増加し、サーバーリソースを圧迫する可能性があります。まずはエラーが出なくなる最小限の増加から試し、サーバーの負荷状況を見ながら調整してください。

設定変更後の手順

  1. Nginx設定ファイルを保存: 変更したNginx設定ファイルを保存します。
  2. 設定ファイルのテスト: 
    sudo nginx -t

     

    このコマンドで構文エラーがないかを確認します。test is successful と表示されればOKです。

  3. Nginxのリロード: 
    sudo systemctl reload nginx

     

    Nginxサービスをリロードして、新しい設定を適用します。

これで、Nginxが大きなHTTPレスポンスヘッダーを適切に処理できるようになり、「upstream sent too big header」エラーは解消されるはずです。

根本的な解決策：Laravelアプリケーション側の最適化

Nginxの設定でエラーを抑制できますが、Laravelアプリケーション側で不必要に大きなヘッダーが生成されている場合は、そちらの最適化も検討することをお勧めします。

  • セッションデータの見直し:
    • クッキーに保存しているセッションデータが大きすぎる場合、データベースやRedisなどのサーバーサイドストレージにセッションを保存するようにLaravelの設定を変更することを検討してください。これにより、クッキーにセッションIDのみが保存されるため、クッキーのサイズを大幅に削減できます。Laravelのセッション設定は config/session.php で変更可能です。
  • クッキーの管理:
    • アプリケーションが設定しているクッキーの数や、個々のクッキーのサイズを減らせないかレビューします。不要なクッキーは削除しましょう。
  • カスタムヘッダーの確認:
    • アプリケーションがレスポンスに含めているカスタムHTTPヘッダーが多すぎないか、または内容が大きすぎないかを確認します。

Nginxの設定調整で当面のエラーは解消されますが、アプリケーションの効率性を高めるためにも、Laravel側のヘッダー生成ロジックを見直すことは良いプラクティスです。

]]> https://otonan-syusyoku.work/archives/2128/feed 0 【AWS】S3への通信量削減の手法 https://otonan-syusyoku.work/archives/1842 https://otonan-syusyoku.work/archives/1842#respond Sun, 15 Sep 2024 07:31:51 +0000 https://otonan-syusyoku.work/?p=1842 便利なストレージサービスであるS3を皆さん使っていますか…!?

静的コンテツの配信サーバーの役割をこなしたり、イレブンナインの耐久性を持ったストレージサービスといった点からAWSの中でも大好きなサービスです。

便利が故にコスト面でネックになってしまう状況が多々あるかと思いましたので、個人的に経験したコストダウンの設計手法をご紹介したいと思いますー！

話すこと

今回は設計について話します。
実装については話しません。

手始めに

まず初めにS3に関わる費用のざっくりとした内訳を確認しておきましょう。

  • ストレージ
  • データ転送（IN/OUT）
  • セキュリティコントロール
  • レプリケーション
  • etc…

一般的な運用を想定すると ストレージ と データ転送 が費用の大部分を占めるはずです。

その中でストレージに関しては、
不必要なデータを置かない, データのライフサイクルを短くする, ストレージクラスを最適なものに設定するなどはありますが、S3にどのようなデータを置くかは各システムで要件が異なってくるため、費用の削減はあまり期待できません。

そうなってくるとデータ転送の部分でコストを最適化するのが必要になってきます。

通信量削減の取り組み

イメージ図

やりたいこと

S3に゙保管しているコンテンツを毎回S3からダウンロードすることを辞めるための設計です。

これにより、キャッシュを用いてS3からの転送量を大幅に減らすことができます。（サイトへのアクセスが多ければ多いほど今回の設計は意味を増してくると思います。

 

添付した画像のフローを改めて文字に起こします。

  1. ページアクセス後に、必要なViewやCSS、画像などがリクエストされます。
  2. まずアプリケーションサーバー（EC2）にコンテンツがキャッシュされているか確認します。
  3. キャッシュに存在する場合は、そのままレスポンスを返します（転送料金が発生しません）。
  4. キャッシュに存在しない場合は、S3からコンテンツを取得し、その後キャッシュします（S3へのアクセスを減らす）。

ChatGPT に計算してもらった

### 東京リージョン（Asia Pacific (Tokyo)）でのS3のデータ転送料金

2023年9月現在、東京リージョンでのS3のデータ転送料金は次の通りです：

- 最初の1GB: **無料**
- 1GB～10TBまでのデータ転送: **$0.114/GB**

これに基づいて、東京リージョンでの転送料金削減を計算します。

### 仮定
- 1回のアクセスでS3からダウンロードされるデータの量：**1MB**
- 1日のアクセス数：**10,000回**
- キャッシュ成功率：**80%**
- 東京リージョンでのS3データ転送料金：**$0.114/GB**

### 計算式（東京リージョン）
1MBのデータが10,000回ダウンロードされる場合：
```
1MB × 10,000 = 10,000MB = 10GB
```

#### S3へのアクセスがない場合のコスト（全アクセスがS3の場合）
```
10GB × 0.114 = $1.14
```

#### キャッシュ導入後のコスト
キャッシュ成功率80%の場合、S3へのアクセスが20%：
```
10,000 × 0.2 = 2,000回
```

2,000回分のダウンロードデータ量：
```
1MB × 2,000 = 2,000MB = 2GB
```

これに対する転送料金：
```
2GB × 0.114 = $0.228
```

#### 削減額
S3にすべてのリクエストを送る場合のコストは**$1.14**、キャッシュを利用した場合のコストは**$0.228**。
したがって、削減できる金額は：
```
$1.14 - $0.228 = $0.912
```

### 結論
キャッシュを使うことで、東京リージョンの場合は、
1日あたり約**$0.912**の転送料金削減が見込めます。

これを1ヶ月（30日）分に換算すると、約**$27.36**の削減が期待できます。

もちろん、アクセス数やキャッシュ成功率、ダウンロードデータのサイズによって結果は変わりますが、
このざっくりとした計算での削減効果は**80%**程度です。

注意点①

キャッシュクリアの方法を適切に設定しない場合、全てのコンテンツリクエストがキャッシュデータを返却してしまいます。

各方面から以下のようなお叱りが届いてしまうので、今回ご紹介した設計を取る場合は、しっかりとキャッシュクリアの戦略を練りましょう。。。

エンドユーザー

ユーザーから保存したデータが古いままなんだけどどうなってるの!?

キャッシュクリア

– バッチ処理にて定期的に削除する（1日1回、6時間毎に…
– データの書き換えのタイミングで該当のキャッシュを削除

注意点②

アプリケーションサーバーにコンテンツを配置するので、アプリケーションサーバー自体のストレージを圧迫する可能性が大いにあります。
アプリケーションサーバーのストレージを外部に移す目的でS3を導入している場合は、今回の手法は取れないので、CDNサービス等を用いてキャッシュさせるのも一つの手になってくると思います。

注意点③

注意点②と同様にアプリケーションサーバーにコンテンツを配置するが故の問題として、センシティブなデータをアプリケーションサーバーに配置する可能性があります。
例： 個人情報の類のコンテンツ（運転免許証、何らかの明細）

これらを一時的にではありますが、アプリケーションサーバーに配置するのがシステム要件的にNGの場合は、絶対に今回の手法は取れません！

最後に

ちょいとした工夫でコストダウンを見込めますので、皆さんも試してみて欲しいですー！

システムの要件等で導入できなければごめんさい！！

]]> https://otonan-syusyoku.work/archives/1842/feed 0 【Laravel】MinIO にputできない問題が情けなさ過ぎた https://otonan-syusyoku.work/archives/1839 https://otonan-syusyoku.work/archives/1839#respond Sat, 17 Aug 2024 08:06:12 +0000 https://otonan-syusyoku.work/?p=1839 概要

個人開発で使用している以下スタックで画像を保存できない問題がおきた。

  • Laravel10
  • MinIO(S3の代わり)
  • Intervention IMage 3

調査

Intervention IMage

Intervention IMage がVersion2 → Version3 で大きく変わったこともあり、使用法を疑ったが、何ら問題はなかった。

debug等の値を見て見たが、問題なし。。。

    /**
     * 画像をリサイズする.
     *
     * @param \Illuminate\Http\UploadedFile $file
     * @return \Intervention\Image\Interfaces\ImageInterface
     */
    public function resize(UploadedFile $file): ImageInterface
    {
        return $this->ImageManager
            ->read($file)
            ->resize(Media::BLOG_IMAGE_WIDTH, Media::BLOG_IMAGE_HEIGHT);
    }


    /**
     * 画像をS3にPutする.
     *
     * @param string $path
     * @param \Illuminate\Http\UploadedFile $file
     * @return bool
     */
    public function putForS3(string $path, UploadedFile $file): bool
    {
        $convertFile = $this->ImageManger->resize($file)->toPng();
        return $this->diskS3->put($path, $convertFile);
    }

minio への通信

ローカル環境をDockerを用いて開発していることもあり、ローカルネットワークが怪しいと何故か閃いた。

以下のコマンドを用いてネットワークを見たところ、同じネットワーク内に存在していたのでコンテナ間の通信は担保されている様子でした。

docker network ls
docker network inspect

ただし、 minio に向けた curl コマンドが返ってこないことが分かった。

原因

調査を進めていくと、サービス名に対してエンドポイントを指定しないといけないことが分かった。

minio:
    image: quay.io/minio/minio:RELEASE.2023-01-18T04-36-38Z
    container_name: 'discovery-gem_minio'

今回はminioとして登録していたので、 .env のエンドぽいとの指定が以下の様に設定する必要がありました。

AWS_ENDPOINT=http:{docker-compose.ymlで指定したport}//minio

たったこれだけのために頭を悩ましたのは悔しすぎる。

 

]]> https://otonan-syusyoku.work/archives/1839/feed 0 LaravelにVueコンポーネントをバインドする方法 https://otonan-syusyoku.work/archives/1720 https://otonan-syusyoku.work/archives/1720#respond Mon, 15 Apr 2024 14:06:40 +0000 https://otonan-syusyoku.work/?p=1720 Laravelプロジェクトを運用している方が jQuery を卒業して Vue または React を導入したい！という悩みに直面する事はしばしばあると思います。

SPAを構築するのはコスト的に対応が難しいため、Laravelプロジェクトの一部にVueを導入する方法を解説しまっす。

環境

  • PHP8.2
  • Laravel10
  • Vue3
    • node v18.19.1
    • npm 10.5.0

やりたいこと

Laravel10の一部にVue.jsを適用する

  • Vueコンポーネントを定義する
  • Vueコンポーネントをバインドする
  • Vueコンポーネントにバックエンドからデータを渡す

手順

Let`s GO

なにわともあれVueのインストール

LaravelはビルドツールにViteを採用しているため、ViteのプラグインとしてVueをインストールします。
（CLIでインストールしても良いと思いますよ！

$ npm install @vitejs/plugin-vue

$ npm install @vitejs/plugin-vue --save-dev

vite.config.js の設定

インストールしたVueを設定ファイルに追記します

import { defineConfig } from 'vite';
import vue from '@vitejs/plugin-vue'; // 追記

export default defineConfig({
  plugins: [vue()] // 追記
});

app.jsを使える状態に持っていく

Vueコンポーネントをグローバルコンポーネントとして登録するために、以下の形でapp.jsを編集します。

下記の記述でやりたいこととしては、コンポーネントの作成及びコンポーネントのマウントです。

import './bootstrap';
import {createApp} from 'vue';
import Alpine from 'alpinejs';
import VueDatePicker from './Components/Utility/CsrfToken.vue';
import VueDatePicker from './Components/Utility/DatePicker.vue';
import AddSalesListModal from "./Components/AddSalesListModal.vue";

window.Alpine = Alpine;

Alpine.start();

const app = createApp({});

// グローバルコンポーネント
app.component('csrf-token', CsrfToken);
app.component('add-sales-list-modal', AddSalesListModal);
app.component('date-picker', VueDatePicker);

// #appにマウント
app.mount('#app');

 

マウント先の指定

app.js でマウント先を id=’app’ としたため、以下のように blade ファイルにマウント先となる記述を設定します。

<body id="app" class="font-sans antialiased flex flex-col min-h-screen">
~
~
~
</body>

コンポーネントの作成

試しにLaravelで生成されるCSRFトークンを扱うコンポーネントを作成します。

このコンポーネントはaxios等で非同期通信を実装するときなどに重宝されるはずですので、皆さんも作っておくと便利ですよん。
（今回は擬似的にpタグにCSRFトークンを出力していますが、本来はしません

<script>
import { ref, onMounted } from 'vue';

export default function useCsrfToken() {
    const csrfToken = ref('');

    onMounted(() => {
        const token = document.querySelector('meta[name="csrf-token"]')?.getAttribute('content');
        if (token) {
            csrfToken.value = token;
        }
    });

    return csrfToken;
}
</script>

<template>
<p>{{ csrfToken }} </p>
</template>

コンポーネントの呼び出し

以下の通りに記述したらVueで取得したCSRFトークンが出力されているはずですぅぅ

<csrf-token></csrf-token>

Vueにバックエンドのデータを渡したいときには、以下の通りに実装してみてください

// Blade
<csrf-token :test='@json($test)'></csrf-token>

// Vue
<script setup>
import { defineProps, ref } from "vue";

const props = defineProps({
    test: Object,
});
</script>

最後に

SPAカッコいいから時間さえあればSPA化したい。

]]> https://otonan-syusyoku.work/archives/1720/feed 0 Larvel10でBreezeのインストールで互換性がないぞと怒られる https://otonan-syusyoku.work/archives/1705 https://otonan-syusyoku.work/archives/1705#respond Sat, 16 Mar 2024 01:24:44 +0000 https://otonan-syusyoku.work/?p=1705 公式の手順に則ってBreezeのインストールを行った結果、互換性エラーでインストールできなかったので備忘録がてら残しておきます。

最終的にバージョン指定でインストールしたら動いたっす。。。。

 

環境

  • PHP 8.2
    • Laravel Framework 10.48.3
  • MySQL 8.0
  • nginx 1.2
  • Docker

エラー

composer require laravel/breeze --dev
[16-Mar-2024 10:09:35 Asia/Tokyo] Xdebug: [Step Debug] Could not connect to debugging client. Tried: host.docker.internal:9000 (through xdebug.client_host/xdebug.client_port).
Using version ^2.0 for laravel/breeze
./composer.json has been updated
Running composer update laravel/breeze
Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Root composer.json requires laravel/breeze ^2.0 -> satisfiable by laravel/breeze[v2.0.0].
    - laravel/breeze v2.0.0 requires illuminate/console ^11.0 -> found illuminate/console[v11.0.0, ..., v11.0.7] but these were not loaded, likely because it conflicts with another require.

You can also try re-running composer require with an explicit version constraint, e.g. "composer require laravel/breeze:*" to figure out if any version is installable, or "composer require laravel/breeze:^2.1" if you know which you need.

Installation failed, reverting ./composer.json and ./composer.lock to their original content.

 

解消手順

インストール可能なVersionを一覧で確認

// 実行コマンド
composer show laravel/breeze --all | less
// 結果
versions : dev-master, 2.x-dev, v2.0.0, 1.x-dev, * v1.29.1, v1.29.0, v1.28.3, v1.28.2, v1.28.1, v1.28.0, v1.27.0, v1.26.3, v1.26.2, v1.26.1, v1.26.0, v1.25.1, v1.25.0, v1.24.1,
 v1.24.0, v1.23.3, v1.23.2, v1.23.1, v1.23.0, v1.22.0, v1.21.2, v1.21.1, v1.21.0, v1.20.2, v1.20.1, v1.20.0, v1.19.2, v1.19.1, v1.19.0, v1.18.2, v1.18.1, v1.18.0, v1.17.0, v1.1
6.1, v1.16.0, v1.15.4, v1.15.3, v1.15.2, v1.15.1, v1.15.0, v1.14.3, v1.14.2, v1.14.1, v1.14.0, v1.13.1, v1.13.0, v1.12.0, v1.11.4, v1.11.3, v1.11.2, v1.11.1, v1.11.0, v1.10.0, 
v1.9.4, v1.9.3, v1.9.2, v1.9.1, v1.9.0, v1.8.2, v1.8.1, v1.8.0, v1.7.3, v1.7.2, v1.7.1, v1.7.0, v1.6.1, v1.6.0, v1.5.0, v1.4.3, v1.4.2, v1.4.1, v1.4.0, v1.3.2, v1.3.1, v1.3.0, 
v1.2.3, v1.2.2, v1.2.1, v1.2.0, v1.1.8, v1.1.7, v1.1.6, v1.1.5, v1.1.4, v1.1.3, v1.1.2, v1.1.1, v1.0.4, v1.0.3, v1.0.2, v1.0.1, v1.0.0, v0.1.0, v0.0.6, v0.0.5, v0.0.4, v0.0.3, 
v0.0.2, v0.0.1, dev-chore/adjusts-workflow, dev-typescript

 

less の結果から1.x 系の最新を選択してインストールする

composer require laravel/breeze:^1.29.1 --dev

 

 

めでたしめでたし

]]> https://otonan-syusyoku.work/archives/1705/feed 0 RESTful APIとSPAの関係についてReactとPHPで解説します https://otonan-syusyoku.work/archives/1674 https://otonan-syusyoku.work/archives/1674#respond Sun, 25 Feb 2024 12:40:20 +0000 https://otonan-syusyoku.work/?p=1674 RESTful APIとは？

What`s up

RESTful APIは、ウェブアプリケーションやウェブサービスで使われるプログラミングインターフェースです。
REST（Representational State Transfer）の原則に基づいて設計されており、ウェブ上のリソースへのアクセスや操作を統一的な方法で提供します。
リソースはURLで識別され、HTTPメソッド（GET、POST、PUT、DELETEなど）を使ってアクセスされます。

[getpost id=”1672″ cat_name=”1″ date=”0″]

SPA（シングルページアプリケーション）とは？

SPAは、ユーザーがアプリケーションを操作する際にページの再読み込みをせずに、必要なデータのみをサーバーから非同期に取得し、動的にページの内容を更新するウェブアプリケーションの形式です。

これにより、従来のマルチページアプリケーションに比べてユーザーエクスペリエンスが向上します。

僕が所属しているチームでもページのリロードが嫌だというユーザーの使用感からSPAへの移行が少しづつ始まってきています。
世間的にもSPAは流行っていますよね。（流行っているから偉いというわけではない。知ることが大事

RESTful APIとSPAの関係性

Let`s GO

SPAでは、ページの初回読み込み時にアプリケーションの全てのコード（HTML、CSS、JavaScript）がロードされます。

その後のユーザーの操作によってデータが必要になる場合、SPAはRESTful APIを通じてサーバーからデータを非同期に取得します。
このデータはJSONやXML形式で返され、JavaScriptを用いてクライアントサイドで処理され、ページの一部分だけが動的に更新されます。

このアーキテクチャにより、SPAはユーザーにスムーズで反応の良いインターフェイスを提供できます。

RESTful APIはこのプロセスの背後にあるデータ通信の基盤となります。

PHPとReactを使った例

ここでは、PHPで書かれた簡単なRESTful APIと、Reactを使ったSPAの例を示します。

PHPによるRESTful API

PHPで簡単なAPIエンドポイントを作成します。この例では、GETリクエストを受け取り、簡単なJSONデータを返します。

<?php 
    header('Content-Type: application/json');
    $response = ['message' => 'Hello, world!'];
    echo json_encode($response); 

    // Response
    //{"message": "Hello, world!"} ?>

このPHPスクリプトは、サーバーに配置してのようにアクセスするとJSONが返されます。

ReactによるSPA

Reactで簡単なSPAを作成し、上記のAPIからデータを取得して表示します。

import React, { useState, useEffect } from 'react';
import axios from 'axios';

function App() {
  const [message, setMessage] = useState('');

  useEffect(() => {
    axios.get('http://yourserver.com/index.php')
      .then(response => {
        setMessage(response.data.message);
      })
      .catch(error => console.error('There was an error!', error));
  }, []);

  return (
    <div>
      <button>{message}</button>
    </div>
  );
}

export default App;

このコードは、コンポーネントがマウントされた後にAPIからデータを取得し、取得したメッセージを表示します。
React（クライアントサイド）とPHP（サーバーサイド）を使った、RESTful APIとSPAの基本的な連携を示しています。

今回のコードでは、データを取得して表示するだけのコードになっていますが、Event処理などによりリロードされることなく動的にページの内容を変更させることが可能です。

セキュリティとパフォーマンスの考慮

SPA（シングルページアプリケーション）とRESTful APIを使用する際には、セキュリティとパフォーマンスの両方に配慮することが重要です。
以下では、これらの観点から基本的なガイドラインをいくつか紹介します。

セキュリティ

  1. HTTPSを使用する
    データの暗号化を確実に行うため、APIとの通信には常にHTTPSを使用します。（当たり前です）
    これにより、中間者攻撃（MITM）のリスクを減らすことができます。
  2. CORSポリシーを適切に設定する
    クロスオリジンリソースシェアリング（CORS）ポリシーを適切に設定し、信頼できるオリジンからのリクエストのみを許可します。
    不適切なCORS設定は、セキュリティリスクを招く可能性があります。
  3. 認証と認可
    JWT（JSON Web Tokens）やOAuthなどの堅牢な認証メカニズムを使用して、APIへのアクセスをセキュアに管理します。
    また、ユーザーの権限に基づいてアクセスを制御する認可も重要です。
  4. 入力の検証とサニタイズ
     SQLインジェクションやクロスサイトスクリプティング（XSS）攻撃を防ぐため、サーバー側とクライアント側の両方で入力値の検証とサニタイズを行います。
  5. 依存関係のセキュリティ
    使用するライブラリやフレームワークのセキュリティ脆弱性に注意し、定期的に更新を行い脆弱性を修正します。

この辺の対策については過去に記事にしていますので時間ある人は読んでみてくださーい

[getpost id=”1618″ cat_name=”1″ date=”0″][getpost id=”1256″ cat_name=”1″ date=”0″]

パフォーマンス

  1. コードの分割
    ユーザーが必要とするコードのみをダウンロードするように、コード分割（Code Splitting）を実装します。
    これにより、初期ロード時間を短縮できます。
  2. キャッシュ戦略の利用
    静的リソースやAPIレスポンスのキャッシュを適切に利用することで、パフォーマンスを向上させることができます。
    ブラウザのキャッシュやCDNの利用が有効です。
  3. 遅延ローディング（Lazy Loading）
     画像やコンポーネントなど、必要になるまでロードしないようにします。
    これにより、初期ロードのパフォーマンスを向上させることができます。
  4. APIの最適化
    不必要なデータの送受信を避けるため、APIのレスポンスをできるだけ小さく保ちます。
    また、必要なデータのみを取得するためのフィルタリングやページネーションをAPI側でサポートします。
  5. フロントエンドのパフォーマンス最適化
    Reactなどのフロントエンドフレームワークを使用する場合は、不要な再レンダリングを避け、メモ化（memoization）や仮想DOMの効率的な利用などのテクニックを活用します。

セキュリティとパフォーマンスは、アプリケーションの設計と開発の初期段階から考慮する必要があります。
これらの基本的なガイドラインを実践することで、ユーザーに安全で快適な体験を提供することができます。

]]> https://otonan-syusyoku.work/archives/1674/feed 0 CORSがわからないからちゃんと勉強してみた https://otonan-syusyoku.work/archives/1618 https://otonan-syusyoku.work/archives/1618#respond Sun, 28 Jan 2024 06:53:06 +0000 https://otonan-syusyoku.work/?p=1618 こんにちは！今日は、Web開発でよく聞くけど意外と理解しづらいCORS（Cross-Origin Resource Sharing）について、一緒に学んでいこうと思います。

Webの世界は複雑で、ちょっとしたことが大きな違いを生むんですよね。CORSもその一つ。

さあ、一緒にCORSを理解してきましょう〜

CORSって何？

まず、CORSって何？って話から始めます。

CORSは、Webページが異なるオリジン（つまり、異なるドメイン、プロトコル、またはポート）のリソースにアクセスする際のセキュリティメカニズムです。

つまり、あなたのサイトが他のサイトのデータを安全に扱うためのルールのこと。これがないと、セキュリティリスクが高まります。

ホスト (Host) インターネット上で情報やリソースを提供するコンピューターやサーバー。各ホストには独自のIPアドレスがあり、インターネット上で特定の位置を持つ。

例：ウェブサイトをホストするサーバー
ドメイン (Domain) インターネット上のアドレスの一部。ウェブサイトや電子メールアドレスを識別するために使われる。人間が理解しやすい形式でサーバーを識別するために用いられる。

例：「example.com」
オリジン (Origin) ウェブページの起源を示す概念。スキーム（プロトコル）、ホスト（ドメイン名）、ポートの組み合わせで定義される。

例：「https://example.com:80」

なぜCORSが必要なの？

Webはオープンでつながっているけど、同時にセキュリティも重要です。

例えば、あなたがログインしているサイトAから、悪意のあるサイトBがデータを盗もうとするといったリスクがあります。

CORSは、このような不正なアクセスを防ぐために存在しているんです。
安全なWebのためには、必要不可欠なんですよ。

CORSの仕組み

CORSの基本は「信頼できるオリジンからのリクエストのみ許可する」ということ。

これは、サーバー側で設定され、ブラウザがこの設定に従います。

サーバーは、リクエストが来たときに「このオリジンからのリクエストはOKかな？」とチェック。

OKならリソースを提供し、ダメなら拒否。これで、安全にデータのやりとりができるようになります。

簡単なCORSの例

例えば、あなたのサイト（example.com）が、他のサイト（api.example.com）からデータを取得したい場合があるとします。

もし、api.example.comがCORSでexample.comを許可していれば、問題なくデータのやりとりができます。

でも、許可されていなければ、「CORSエラー」が発生してアクセスできないんです。

CORSをどう扱う？

開発者としては、CORSは頭痛の種になることも。

しかし、適切に設定することでセキュリティを確保しつつ、必要なデータ交換も可能になります。サーバーの設定を見直したり、必要に応じてオリジンを許可リストに追加することが大切です。

設定方法

素のPHP

※WEBサーバーにて設定することも可能ですが、今回はPHPでの実装を想定。

header("Access-Control-Allow-Origin: http://example.com");
header("Access-Control-Allow-Methods: GET, POST, PUT, DELETE");
header("Access-Control-Allow-Headers: Content-Type, X-Requested-With");

/**
* - http://example.com からのアクセスを許可
* - 許可メソッドは GET, POST, PUT, DELETE
* - リクエスト中に許可されるHTTPヘッダー
*     - Content-Type（リソースのメディアタイプ
*     - X-Requested-With（通常、Ajaxリクエストを識別するために使用される）
*/

Laravel

※Laravel 7.x以降ではデフォルトでCORS設定が組み込まれているっぽい。

return [
    'paths' => ['api/*'],
    'allowed_methods' => ['*'],
    'allowed_origins' => ['http://example.com'],
    'allowed_origins_patterns' => [],
    'allowed_headers' => ['*'],
    'exposed_headers' => [],
    'max_age' => 0,
    'supports_credentials' => false,

    /**
     * - http://example.com からのアクセスを許可
     *   'allowed_origins' => ['http://example.com']
     *   この設定は、http://example.com からのリクエストを許可します。
     * 
     * - 許可されるHTTPメソッド
     *   'allowed_methods' => ['*']
     *   この設定は、すべてのHTTPメソッドを許可します。特定のメソッドのみを許可する場合は、
     *   ['GET', 'POST', 'PUT', 'DELETE'] のように配列を編集します。
     * 
     * - 許可されるHTTPヘッダー
     *   'allowed_headers' => ['*']
     *   この設定は、すべてのHTTPヘッダーを許可します。特定のヘッダーのみを許可する場合は、
     *   必要なヘッダーを配列に追加します。
     */
];

 

まとめ

CORSは、Webの安全性を保つための重要なメカニズム。最初は複雑に感じるかもしれませんが、基本を理解すれば、より安全で効果的なWebアプリケーション開発が可能になります。

これにてCORSの基本を何となく理解！

]]> https://otonan-syusyoku.work/archives/1618/feed 0 自分で作ったサービスで売上を上げるのめちゃくちゃ難しいやんけ https://otonan-syusyoku.work/archives/1613 https://otonan-syusyoku.work/archives/1613#respond Sat, 27 Jan 2024 01:55:46 +0000 https://otonan-syusyoku.work/?p=1613 こんにちは。都内でPHPerとして勤務している三流プログラマーです。

本業とは別に取り組んでいた個人開発でマネタイズができず、サービスを終了させてしまったのでここで供養させてください。

RIP My Service…

作ったもの

HP 兼 予約サイト 兼 ECサイトなるシステムを開発しました。

僕が沖縄県出身ということもあり、沖縄の個人経営を営んでいる小さな企業さんを相手に営業の肩代わりをすることを目的にシステムを開発しました。

というのも沖縄県は観光地として有名でありながらもHPすら持たず、地元の口コミのみで経営を行っているお店が多々ある状態でした。

せっかくの観光地でありながらお客様を呼び込めないのはかなりもったいないという思いから作った次第でございます。

技術構成

デザイン Tailwind + DaisyUI
フロントエンド React
バックエンド Laravel10
DB RDS(MySQL8.x)
決済 Stripe
インフラ サーバー：EC2
DB：RDS
ファイルサーバー：S3
その他 Docker

マネタイズポイント

物販購入

沖縄ならではの商品が展開されるEC機能を開発しました。

1商品当たり個別に x％ の手数料をいただく契約になります。

予約

美容院やレジャー施設の予約を受け付ける機能を開発しました。

こちらもEC同様に1予約あたり、x円の手数料 or オプション契約 のどちらかを契約する想定でした。

売り方

沖縄出身ではあるものの都内で勤務しているということもあり現地での営業活動ができないという状況でした。
そのため、現地で営業活動を行ってもらうために地元の友だちに「俺はこれから月100万円稼ぐシステムを開発するから営業をしてくれ」と大きく誇張した言い分を持って営業活動をしてもらいました。

その友人は面白そうだからという理由で快く引き受けてくれ、以下のマーケティング手法で営業を行ってもらいました。

  • SNS
    • Instagram
    • Twitter
  • ブログ

先に結論から入るのですが、期間としては6ヶ月間行ってもらい、皆さんの想像通り契約は1件も入らなかったです。

なぜ売れなかったのか

知名度

これは誰しもが考えることだと思うのですが 認知されていないサービスにお金を払う ことは避けたいはずです。

尚更、登記もしていない個人が開発したシステムに対して自分の命であるお金を注ぐことはあり得ないです。

考えられる手法としては以下の手法が取れるはずです。

  • 正しい営業をする
  • 受託等で知名度を得る
  • その他のサービスで知名度を得る（知名度が無いことによる無限ループが発生する…）

お客様が安心してこのサービスにはお金を投資できると胸を張って言えるようなシステムを構築するのは難しいですね。。。

効果を得られるか不安

知名度がないという理由にも近しいですが、当システムを使用することで利益を得られることに対する不安を拭い去る事はできませんでした。

なぜなら契約が1件もないということは実績が無いということですからお客様からすると不安しかありません。

世の中のスタートアップはどうやって利益を得ているんですか？？

県民性

こちらは確固たるデータがある訳ではないんですが、ハードに仕事をしないという県民性を見誤っていた可能性がある事を感じています。

沖縄は「のんかーな性格（のんきな性格）」と呼ばれる人が多い印象です。

事実として僕の知っている沖縄の経営者では食べていける分を稼げて楽しい毎日を送ることが大切という人が多いです。（4人だけしか知りませんが…）

そういった考えを持っている人に対して業務を効率化して売上を伸ばしましょうなんて言っても「忙しくなるなら現状のままで」といった答えが返ってくるに決まっています。

そのあたりをしっかりと調査する or ターゲットを先に見つける事が大切かなぁという印象です。

反省

僕はゴミを作ってしましました。

誰にも使われないシステムなんてゴミです。ただのゴミクズです。

今回は僕一人と頭の悪い友人の時間だけが溶けただけで済んで本当に良かったです。（実際には5万ほど運用費としてお金を使いました。）

仮に起業という形でサービスを開発していた場合は廃業に大きく近づいていたので、個人開発の一環でここまでの勉強ができたのは僕の才能かもしれません。笑

まだまだ作りたいものはあるので引き続き頑張っていきたいですねぇ〜

]]> https://otonan-syusyoku.work/archives/1613/feed 0 【Exif削除】PHPで写真から「余計な情報」を消す方法をマスターしよう https://otonan-syusyoku.work/archives/1611 https://otonan-syusyoku.work/archives/1611#respond Sun, 21 Jan 2024 08:00:49 +0000 https://otonan-syusyoku.work/?p=1611 PHPエンジニアのみなさん、こんにちは！
今日はPHPで写真からExifデータを取り除く方法について、わかりやすく解説していこうと思います。知ってると便利な小技ですよ。

Exifデータって何？

Exifデータって、デジタル写真に含まれる「隠れた情報」のこと。
これには撮影日時や場所、使われたカメラの設定などが含まれています。

便利な情報なんだけど、これが原因でプライバシーが漏れることも。だから、写真をネットにアップする前には、このExifデータを削除しておくのが安全策なんです。

[getpost id=”1608″ cat_name=”1″ date=”0″]

PHPでExifデータを消すには？

さて、PHPでExifデータを削除する方法ですが、意外と簡単にできます。

まずは、GDライブラリを使います。
これはPHPで画像を処理する際によく使われるライブラリです。
以下のようなコードでExifデータを削除できますよ。

<?php
$image = imagecreatefromjpeg('example.jpg'); // JPEG画像を読み込む
imagejpeg($image, 'result.jpg'); // 画像を保存することでExifデータを削除
imagedestroy($image); // メモリを解放
?>

 

このコードで何が起きているかというと、imagecreatefromjpeg関数で画像を読み込んで、imagejpeg関数で新しいファイルとして画像を保存しています。

この保存のプロセスで、Exifデータが取り除かれるんですね。

※ imagecreatefromjpeg は楽に確認したく使用しました。使用している技術に合わせて適切なもの使って下さい。

画質を保ちつつExifを消すコツ

画質を落とさずにExifデータだけを削除したい場合は、imagejpeg関数の第3引数に画質（0から100）を指定します。100が最高画質です。

この方法で、画像の見た目はそのままに、Exifデータだけを上手く取り除くことができますよ。

imagejpeg($image, 'result.jpg', 100);

まとめ

PHPを使ってExifデータを削除するのは、プライバシー保護のためにも重要です。

サイトやアプリでユーザーから写真を受け取る場合は、この処理を加えることで安心して提供できますね。

みなさんも、ぜひこのテクニックを試してみてください！

]]> https://otonan-syusyoku.work/archives/1611/feed 0