Photoruction工事中!

Photoructionの開発ブログです!

DTOクラスの基本

はじめまして、BPOチームでエンジニアやってますkazuです🦌

最近業務で、DTOクラスを教えてもらったので理解を深めようと思い記事にしてみました。

そもそもDTOクラスとは

DTO(Data Transfer Object)とは、システム間やレイヤー間(例:UIとビジネスロジックビジネスロジックとデータベースなど)でデータを転送する時に用いられるオブジェクトのこと。

APIやDBから受け取ってきた生のデータを扱いやすい形に変換して、一貫した形式でアプリケーション内部に受け渡しができる。

特徴

  • ロジック(ビジネスロジックドメインロジック)を持たない
  • プロパティを保持するシンプルなクラス
  • 入力値の以上や型揃えの不備を発見しやすくなる

つまり、あくまで「データの運搬がメイン」のオブジェクトで、ビジネスロジックドメインロジックのような業務ルールや制約などの処理に含まれず、純粋にデータのやり取りを担うことを目的としている。

なぜ、DTOを使う必要があるのか

1. レイヤー間の依存を減らす

例えば、ドメインオブジェクト(エンティティ)をUI層に直接渡すと、UI層で余計なフィールドやメソッドを操作できてしまい、依存関係が複雑になったりする。

DTOを挟むことで、UI層に必要な情報だけを切り出し、UI層とドメイン層の結合度を下げることができる。

2. データのまとまりを担保する

データをひとつのオブジェクトにまとめることで、転送やシリアライズが簡単になり、データの受け渡しを行う関数やAPIの引数/戻り値を整理しやすくする。

3. セキュリティやバリデーションのしやすさ

データチェックやバリデーションをDTOクラスの生成過程で扱いやすくなる。

DTOがよく使われるシュチュエーション

Webアプリケーションのリクエスト/レスポンス

マイクロサービス間通信

  • マイクロサービス同士が通信する際、ServiceA → DTO → ServiceBのようにデータ転送をする

レイヤードアーキテクチャ

上記のような間で、Entityをそのまま渡すと密結合になるため、DTOを介して疎結合に保つ。

サンプルコード

class OrgDTO {
  constructor(contents) {
    this.orgId = this.parseIntValue(contents["orgId"]);
    this.email = contents["email"];
    this.name = contents["name"];
  }

  parseIntValue(value) {
    return value ? parseInt(value, 10) : null;
  }
}

function main() {
  // サンプルデータ(外部から取得する想定のデータ)
  const contents = {
    "orgId": "1",
    "email": "aaa@example.com",
    "name": "test"
  };

  // DTOクラスのインスタンスを生成
  const result = new OrgDTO(contents);
  console.log("result", result);
}

main();

例えば、このように入力値の orgId が文字列として与えられる場合、parseIntValue 関数を利用して文字列型を Int 型に変換することができます。このように、生のデータをアプリケーション層で扱いやすい形に整形することで、コードの可読性と保守性を大きく向上させることができます。

また、データの取り扱いに役割を限定することで、ドメインロジックやビジネスロジックとの結合度を下げることができ、システム全体の見通しが良くなります。結果として、その後の処理でデータを扱う際に余計な手間が減り、開発効率が向上しそうです。

まとめ

  • DTOクラスは、「データをやり取りするだけ」のオブジェクト
    • ロジックを持たず、転送用フィールドとアクセサだけを持つのが基本
  • レイヤー間の依存度を下げ、コードの可読性を上げるために利用
    • 疎結合を保ち、メンテナンス性を高めるのに役立つ
  • Webアプリやマイクロサービス、レイヤードアーキテクチャで使われることが多い
    • リクエスト/レスポンスやDBとのやりとりなど
株式会社フォトラクションでは一緒に働く仲間を募集しています

www.wantedly.com

開発組織オフラインイベント Photoruction X ✨

初めまして!CREとしてエンジニアをやってますkazuです🦌

今回は、12月に開催された開発組織オフラインイベント「Photoruction X」についてお届けします👏 企画運営メンバーとして約2ヶ月間、イベントの実現に向けて尽力してきました。当日の様子や運営メンバーの取り組み、そしてPhotoructionの魅力について少しでも知っていただける内容となっています。ぜひ最後までご覧ください!

Photoruction Xで達成したかったこと

各部署・各チーム・各メンバー間でのX(交流点)を作り、コミュニケーションの場を生み、未来につながるコミュニティを作ることを目的としています。今回のイベントでは、X(交流点)をたくさん生み出すことを目標とし、その目標を達成させられるようなコンテンツをいろいろ用意しました!

Photoruction X ロゴ

当日のイベント風景

当日は、運営の挨拶から始まり、中村CTOからこれからどんな組織にしていきたいかの共有、レクリエーションなどを行いながら、普段接点を持つことがないメンバーとの交流をできるようにしました。

イベント会場としてお借りしたのは、スペースマーケット本社になります✨ spacemarket.co.jp

広々とした空間で、テーブルなども臨機応変にレイアウトを変えたりできるので、使い勝手が良かったです!また、カウンターもついていることから、料理の提供もしやすく何より料金が安くかったので運営としてはとても助かりました🥺ありがとうございます!

気になる方は、こちらでチェックしてみてください↓↓↓

https://www.spacemarket.com/

Photoruction X 開催🎉

僕は司会を務めさせていただきました👏

内心準備したものを楽しんでもらえるかドキドキしていました(笑)

運営からの挨拶

はるっちと僕からの挨拶!(右側見切れてますが笑)

中村さんからも挨拶をいただきました!

企画の趣旨を説明しつつ本日のタイムスケジュールをお伝えしました!

テクノロジー本部ココロエとはなんだろう🤔

テクノロジー本部のココロエ

中村CTOから、テクノロジー本部が目指すこれからについての共有の時間です⏰

テーマは、「あざとく、優しく、組織力向上への道」ということで、ホスピタリティとあざとさで組織力向上を目指そうというものです。

ホスピタリティとは

相手の状況や感情を理解し、ベストなアクションを取ること

ホスピタリティが高い組織のメリット

  • 心理的安全性の向上
  • スムーズなコミュニケーション
  • 持続可能な働き方
  • 信頼関係の構築

「ホスピタリティが高い組織のメリット」を再認識する中で、自分自身のホスピタリティ力をさらに高めることで、組織の成長により大きく貢献できると感じました。心理的安全性やスムーズなコミュニケーションを通じて、信頼関係を構築し、持続可能な働き方を実現するために、自分にできることを今後も追求していきたいと思いました!

あざとさ

スマートに価値や成果を伝え、共感や支持を得る力

あざとさが組織にもたらす強み

  • 外部への魅力発信
  • 競争力の向上
  • チームのモチベーションアップ

スマートに価値や成果を伝える力は、組織の魅力を外部に発信し、共感や支持を得るうえで非常に有効だと感じます。この力が競争力の向上や人材確保にも繋がる点に気づき、新たな視点を得ることができました。「あざとさ」という言葉のポジティブな使い方にも感心しました笑

Photoruction Labo 中間報告会

Photoruction Laboってなに?ってところから始まり、各チームのプロダクトの発表を行いました。

こちらは、僕とCREチームリーダーのよしきさんで司会進行!

Photoruction Xの目的と似ていますが、チーム単位での開発を行うことで人と人同士の繋がりを増やして、組織力向上を目指そうというのが主旨となっています。

そして、各チームのプロダクトの発表へ…

fracchiでは、flutterを用いて日記を記録して投稿するアプリを作成しています。

fracchiは、先日開発合宿にも行ってるので、気になる方はこちらをご覧ください↓↓↓

https://kojichu.photoruction.com/entry/2024/11/27/090000

シヨウワカールでは、AIチャットbotを作成し、使用の不明点について質問したらそれに回答してくれるプロダクトを開発しています。

これが実現したら、CREの仕事も大助かり…🥺

最後は、day1チームの発表です!

こちらは、VRを用いてオフィスを再現させています。

UnityとBlenderを用いているのですが、BlenderとUnityとの互換性がまあ悪い。笑

普段のプログラミング言語とも異なるツールなので、最初から覚えるのはかなり苦労しました💦

それでも、どうにか「誰がどうみてもオフィスだよね」くらいのレベル感には到達。

長い道のりでしたが、残りの数ヶ月でものを掴んだり勝手に何かかが動いたりまで実装できるように頑張ります💪

レクリエーション

お待ちかねのレクリエーション👏

今回は、以下の4つを企画しました!

意外に盛り上がったのが、スポーツスタッキングでした!笑

各チームがタイムアタック形式で競い合い、隣同士でプレイの様子が見える状況が白熱した雰囲気をさらに引き立てていました!競技中の緊張感とガヤの声で、会場全体が一体感に包まれていました!

最終的に優勝したのはチームAでした🎉

なんと優勝チームには、Amazon ギフト5,000円の券 or 沖縄出張券が与えられるという豪華景品🥺

最終的な得点

懇親会🍣

今回は、出張寿司の方に来てもらいその場でお寿司を握ってもらいました!

じつは、出張寿司で来てくれたゆうじくんは元々友達であり、今回の企画運営を任されたタイミングで、「ゆうじの寿司をぜひ食べてほしい!」と思い、企画に練り込んでいました笑

皆さん美味しいと言いながら、もりもり食べてくれたので僕としては大満足でした😭

ゆうじくんのインスタ気になる方いましたら、ぜひこちらもご覧ください↓↓↓

https://www.instagram.com/yuji.m_sushi?igsh=YXMxMTMxYW1sZXR0

最後はみんなで写真を撮って、終わりました〜

まとめ

初めてメンバーだけで運営を行いましたが、コンセプト設計からコンテンツ企画、会場選定、予算管理、社内広報まで、さまざまな制約の中で「どんな体験を提供するのか」「何を達成するのか」を逆算しながら取り組みました。その過程では多くの葛藤もありましたが、無事に当日を迎え、イベントを成功させることができました。そして、何よりも参加者の皆さんの笑顔を見られたことが大きな励みとなりました!

イベント運営に関わることができて、本当に良かったです!

中村さん機会をくださり、ありがとうございました🙇‍♀️

P.S

春っち、武井さん、期間限定チームだったけど一緒にイベント作りできた事は一生の思い出です。 二人とイベント作りできてとても楽しかったです!最高のチームだったと思います。 またチーム組む機会あったらよろしくね🤝

株式会社フォトラクションでは一緒に働く仲間を募集しています

www.wantedly.com

Photoruction Labo 開発合宿@LIFORK大手町 🖥️

こんにちは、Build Web所属の田村です。

何度か記事になっていますが、弊社テクノロジー本部ではPhotoruction Laboという開発イベントを実施しています。

私たちのチーム”fracchi”は主にFlutterを使って何か作ってみよう!をテーマに進めていますが、このたび11月2日(土)に開発合宿に参加しましたのでレポートします!

↓↓↓Photoruction Laboについては、こちらの記事を参考にしてください

kojichu.photoruction.com

なぜ開発合宿に行くことにしたのか

fracchiは2.5名体制となっていて、メンバーは

  • 田村 Build Webグループ リーダー
  • ヤスィン Build Mobileグループ リーダー
  • 田中 CREグループ リーダー ←開発はせずfracchiの面倒を見てくれるマネージャー的存在

となっています。

週あたり4時間程度Laboのために割り当てて進めることにしていますが、そうは言ってもお互いにリーダー職でとても多忙な毎日を送っているため、なかなかLaboのために時間をとることが難しい😓

実際Flutterの開発環境を5月に作成し、その後だいぶ間が空いて8月下旬にやっと最初の実装コミットというスローペース。というか、全く進んでいない・・・。

ここでガツンと進捗を出そうぜ!とマネージャー田中さんがあれこれと計画をしてくれたことがきっかけでした。

VRチームから”淡路島で合宿して楽しかったし良かったよ!”と聞き当初は日光や熱海で計画しましたが、開発に集中することと手軽さに重点をおき都内のコワーキングスペースで開催することになりました。

↓↓↓fracchiの開発合宿、場所はこちら

lifork.jp

https://maps.app.goo.gl/A21t33NVGrc6umRVA

↓↓↓ちなみにVRチームの淡路島合宿の記事

kojichu.photoruction.com

開発合宿の様子

合宿といっても都内コワーキングスペースということで、最初は「いつもの仕事と変わらんだろう🤔」ぐらいに実は思っていましたww

“ホテルに缶詰”みたいな感じですかね。ペンが進まない作家が編集者につかまって逃げられないように閉じ込められるアレ。

ところが予想に反してこのコワーキングはとても趣があって雰囲気も最高!充実の作業環境!👍️

当初のイメージとはまったく異なり、数カ月分の進捗以上のものをたった一日で生み出すことができました🙌

エンジニアの2人

これから始めるところですね💪

周辺の様子

緑もいっぱいで外の喧騒はまったく気になりませんでした👍️

シェアオフィスの中

インテリアも落ち着いた雰囲気でとてもリラックスして作業に集中することができます👨‍💻

作業スペース①
作業スペース②
作業スペース③

こんな作業スペースもあります

まるでお金持ちの友達の家にお呼ばれしたかのよう

これはこれで気分転換できそう

その他の設備

おいしいコーヒーを淹れることができます☕

作業に必要なものはなんでも揃ってる(モニターやケーブル等も)

打ち合わせもできます

ランチ

霧雨けむるアンニュイな土曜にがんばる私たちのために田中マネージャーが予算取りしてくださいました🍣

遠方への移動費や宿泊代を削減してよかったと思えた瞬間でした🫣

最後に:開発合宿が終わって思うこと

通常の業務の中でLaboのためにうまく時間を取ることができなかったのですが、こういう機会があったことでそれをうまくカバーすることができました🎉

また私はいつもは田舎でリモートワークをしていてそれはそれでメリットもたくさんあるのですが、たまにはオフィスで仕事をしたりチームのメンバーの顔を見たいなぁと思うことがあります。

いつもヤスィンさんとは業務ではグループ間の共有・調整などのやり取りが主となり一緒に作業をすることはほとんど無いのですが、同じ場所で同じ目標に向かって手を動かすことで初めてわかることがたくさんありました。

ランチや徒歩移動のときにはお互いの家族のこと、今まで経験してきたこと、文化の違いなどいろいろ話すことができました👍️

現状、弊社テクノロジー本部はグループ・チームが違うとガクッとコミュニケーション量が減り同じエンジニア職でありながらお互いのことをあまりよくわかっていないということが少なくないです。

Photoruction Laboの目的として個人のスキルアップもありますが、希薄になりつつあるエンジニア間のコミュニケーション機会を増やしてより強い組織にしていくことも大事なことだと思ってます。

合宿ではオフラインで接することで良い体験を得ましたが、今後オンラインでのコミュニケーションにも活かしていけたらと思いました。

小声)そして・・・なんとかゴールに辿り着きたい ←切実🫠

おまけ:今回の出張のおみやげ

東京駅で新幹線に乗る前に買ったサンドクッキーとフィナンシェ🍪

前日のオフィス出勤と合わせて2日間家をほったらかしてしまいましたが、家族にとてもおいしいと喜ばれました👍️

coco-ris.jp

https://maps.app.goo.gl/BvsAiq78BUp2dwjbA

株式会社フォトラクションでは一緒に働く仲間を募集しています

www.wantedly.com

Laravel + Brefで実現するサーバーレスアプリケーション

はじめに

BPOチームの春冨です。

今回は業務でサーバーレスアプリケーションを実装することになり、Brefというツールを使用する予定です。初めて使うツールなので、まずは簡単に試してみました。この記事ではその実践内容を紹介します。

Bref とは

Brefは、LaravelなどのPHPアプリケーションをAWS Lambda上で動作させるためのツールです。通常、LambdaはNode.jsやPythonJava、Goといったランタイムを公式にサポートしていますが、PHPは含まれていません。Brefはこのギャップを埋めるため、独自のPHPランタイムを提供し、PHPアプリケーション(例:Laravelアプリケーション)をAWS Lambda上で実行可能にします。

システム構成

システム構成図

今回作成するシステムの構成図は以下の通りです。

  • 静的ファイルはCloudFront経由でS3から取得
  • 動的なリクエストはCloudFrontからAPI Gatewayを介してLambdaに送信し、バックエンドで処理

バックエンドはLaravel + Brefで、フロントエンドはReactで実装してビルドしたものをS3に配置するSPAとして構築しました。

実装手順

実装はバックエンドとフロントエンドに分けて進めます。

バックエンド

LaravelでAPIを実装

api.phpに以下のようなコードを追加し、簡単なレスポンスを返すようにしました(Laravel 11を使用)。

<?php

use Illuminate\Support\Facades\Route;

Route::get('/hello', function () {
    return response()->json(['message' => 'Hello World!']);
});

Brefのセットアップ

brefの公式ドキュメントに従い、Serverless FrameworkのインストールやAWSアクセスキーの設定を行います。今回はbrefというプロファイルを作成し、デプロイに使用しました。

Laravelにbrefをインストールし、デプロイ

composerを使ってbrefをインストールします。

composer require bref/bref bref/laravel-bridge --update-with-dependencies

次に、serverless.ymlをコマンドで生成します。

php artisan vendor:publish --tag=serverless-config

デフォルトのserverless.ymlを編集します。

  • regionap-northeast-1に変更
  • profileに作成したプロファイル名を追加
  • runtimephp-83-xxxに変更(Laravel 11にはPHP 8.3が必要なため)
service: laravel

provider:
    name: aws
    # The AWS region in which to deploy (us-east-1 is the default)
    region: ap-northeast-1
    # Environment variables
    environment:
        APP_ENV: production # Or use ${sls:stage} if you want the environment to match the stage
        SESSION_DRIVER: cookie # Change to database if you have set up a database
    profile: bref

package:
    # Files and directories to exclude from deployment
    patterns:
        - '!node_modules/**'
        - '!public/storage'
        - '!resources/assets/**'
        - '!storage/**'
        - '!tests/**'

functions:

    # This function runs the Laravel website/API
    web:
        handler: public/index.php
        runtime: php-83-fpm
        timeout: 28
        events:
            - httpApi: '*'

    # This function lets us run artisan commands in Lambda
    artisan:
        handler: artisan
        runtime: php-83-console
        timeout: 720 # in seconds
        # Uncomment to also run the scheduler every minute
        #events:
        #    - schedule:
        #          rate: rate(1 minute)
        #          input: '"schedule:run"'

plugins:
  - ./vendor/bref/bref

以下のコマンドでデプロイすると、API GatewayとLambdaが作成されます。

serverless deploy

フロントエンド

Reactアプリケーションを作成

npx create-react-app my-app

ReactからLaravelのAPIを呼び出す機能を実装

App.jsに以下のコードを追加し、LaravelのAPIから取得したデータを画面に表示させます。

import React, { useEffect, useState } from 'react';
import logo from './logo.svg';
import './App.css';

function App() {
  // useStateを使ってAPIから取得したデータを保存する
  const [apiData, setApiData] = useState(null);

  // useEffectを使ってコンポーネントのマウント時にAPIリクエストを送信
  useEffect(() => {
    // Laravel APIへのリクエストを送信
    fetch('/api/hello')
      .then(response => response.json())  // レスポンスをJSON形式に変換
      .then(data => {
        setApiData(data);  // APIのデータをstateに保存
      })
      .catch(error => {
        console.error('Error fetching data:', error);
      });
  }, []);  // 空の依存配列により、この効果はコンポーネントが初回レンダリングされたときだけ実行される

  return (
    <div className="App">
      <header className="App-header">
        <img src={logo} className="App-logo" alt="logo" />
        <p>
          Edit <code>src/App.js</code> and save to reload.
        </p>
        <a
          className="App-link"
          href="https://reactjs.org"
          target="_blank"
          rel="noopener noreferrer"
        >
          Learn React
        </a>
        {/* APIデータが存在する場合に表示 */}
        {apiData && <p>API Response: {apiData.message}</p>}
      </header>
    </div>
  );
}

export default App;

ReactをビルドしてS3に配置

npm run build
aws s3 sync build/ s3://your-bucket-name

CloudFrontの設定

最後に、CloudFrontを作成し、S3とAPI Gatewayをオリジンとして設定します。

/api/*パスパターンでAPI Gatewayに向くようにビヘイビアを設定し、それ以外はS3に向くようにします。

以上で実装が完了です。CloudFrontのURLにアクセスすると、ReactアプリにLaravelのレスポンスが表示されるようになります。

まとめ

今回の記事では、LaravelとBrefを使用してサーバーレスアプリケーションを構築する方法を紹介しました。Brefを利用することで、AWS Lambda上でLaravelを動作させる環境を簡単に構築できることが分かりました。

株式会社フォトラクションでは一緒に働く仲間を募集しています

www.wantedly.com

LambdaからRDSにアクセスができない理由

初めまして!CREとしてエンジニアをやってますkazuです🦌

社内システム自動化プロジェクトのインフラ構成を考えていた際、本番環境のRDSにLambdaからアクセスする必要があり、「とりあえずRDSにLambdaからアクセスさせればいいんだな〜」と思っていたところ、実は簡単にアクセスできるものではないことを知ったので、その時調べたLambdaとRDSの関係についてまとめた記事になります。

※こちらの図は、業務で作成したインフラ構成図とは異なるものです。

そもそも、LambdaからRDSに接続することになったワケ

本プロジェクトは、要件定義から開発まで一貫して担当しているプロジェクトであり、これまで社内で手動でやっていたのものを自動化する事が目的です。最終的にはLambdaからRDSにアクセスをし、本番DBの値を更新する事でその結果をSlackに通知する事を目指しています。

正直なところAWSに関する知識は乏しく、「Lambdaを呼び出して実行すれば、本番DBを更新できるだろう」と考えていました。

しかし、インフラ構成図をもとにフィードバックを受ける中で、LambdaからRDSへのアクセスが簡単ではないことを知り、その理由について疑問が湧いてきたので調べることにしました。

なぜ、LambdaからRDSへ接続ができないのか

  • RDSの作成場所がVPC内であること
  • VPCに接続するには、同じVPCのプライベートサブネット空間にLambdaを配置する必要がある

RDSの作成場所がVPC内であること

Auroraなどの RDSは、基本的にVPC内のプライベートサブネットに配置されます。これは、セキュリティ面を考慮して、外部から直接アクセスできないようにするためです。パブリックネットワークに露出させないことで、外部からの不正アクセスリスクを低減し、安全性を確保しています。これにより、データベースを社内や関連システムからのみアクセス可能な状態に保つ事ができます。

プライベートサブネットにあるRDSに接続するには

VPC内のプライベートサブネットにある RDSに接続するためには、Lambdaも同じVPCのプライベートサブネット内に配置する必要があります。Lambdaの配置場所は、パブリックサブネットとプライベートサブネットのどちらかを選択する事が可能ですが、RDSとの接続を前提とする場合は、プライベートサブネット内にLambdaを置きます。

Lambdaがインターネットと接続できない

ここで、一つ問題があります。Lambdaをプライベートサブネット内に配置することで、RDSへのアクセスは可能になりましたが、インターネットとの接続ができません。

プライベートサブネット内にあるLambdaが外部のAPIやインターネットリソースにアクセスする必要がある場合、以下のような方法を使ってインターネット接続を実現する事ができます。

NATゲートウェイを使う

NAT(Network Address Translation)ゲートウェイは、プライベートサブネット内のリソースがインターネットに接続できるようにするAWSのサービスです。 NATゲートウェイをパブリックサブネットに配置し、プライベートサブネット内のLambdaからインターネットにリクエストを送ると、そのリクエストはNATゲートウェイを通じてインターネットに出ていきます。これにより、プライベートサブネット内にあるLambdaが安全に外部通信を行えるようになります。

NATゲートウェイは一方向の通信を許可する仕組みであり、インターネットからの直接アクセスはできないため、セキュリティを保ちつつインターネット接続する事が可能です。

まとめ

今回は、LambdaがRDSにアクセスできない理由について解説しました。まだまだAWSについては勉強が必要そうです。

株式会社フォトラクションでは一緒に働く仲間を募集しています

www.wantedly.com

laravel 11 でauth0 を使ったユーザー認証を実装

はじめに

はじめまして、BPOチームの春冨です。

今回はLaravel 11 で Auth0 を使用したユーザー認証を実装する手順についての記事になります。

その前に、Auth0 を使用した認証フローについて簡単に説明します。

認証フロー

今回は外部 ID プロバイダーとして Google を使用し、Google アカウントでログインするシナリオを想定しています。

  1. ユーザーがシステムにログインリクエストを送信
  2. システムは Auth0 のログイン画面にユーザーをリダイレクト
  3. ユーザーは Auth0 経由で Google に認証情報を送信
  4. Google での認証が成功すると、Auth0 がシステムに認証トークンを返す
  5. システムはトークンをセッションに保存し、ログイン成功ページを表示

これ以降、システムはセッション内の認証トークンを使用して、ユーザーのログイン状態を確認できます。

auth0を使用したログイン認証フロー

実装手順

ここからは、Laravel プロジェクトに Auth0 を使用した認証を実装する手順を説明します。Auth0 の導入にはauth0/loginライブラリを使用します。バージョンは7.15.0を利用します。

環境

  • PHP: 8.2
  • laravel: 11.0
  • auth0/login: 7.15.0

Auth0 ライブラリの導入と設定ファイルの追加

まず、Composer で Auth0 のライブラリをインストールします。

composer require auth0/login:7.15 --update-with-all-dependencies

以下のコマンドで、config/auth0.php 設定ファイルが作成されます。

php artisan vendor:publish --tag auth0

設定ファイルの詳細はこちらで確認できます。

Auth0 CLI を使ってアプリケーションを登録

Auth0 CLI を使用してアプリケーションを登録します。

ダッシュボードから手動で登録することも可能です。

まず、Auth0 にログインします。

auth0 login

続いて、アプリケーションを作成します。

auth0 apps create \
  --name "My Laravel Application" \
  --type "regular" \
  --auth-method "post" \
  --callbacks "http://localhost:8000/callback" \
  --logout-urls "http://localhost:8000" \
  --reveal-secrets \
  --no-input

次に、API を登録します。

auth0 apis create \
  --name "My Laravel Application API" \
  --identifier "https://github.com/auth0/laravel-auth0" \
  --offline-access \
  --no-input

.env ファイルに必要な値を設定

Auth0 のダッシュボードで作成したアプリケーションと API の情報を確認し、以下の値を .env ファイルに記載します。

# Auth0 ドメイン (例: tenant.region.auth0.com)
AUTH0_DOMAIN=...

# クライアントID
AUTH0_CLIENT_ID=...

# クライアントシークレット
AUTH0_CLIENT_SECRET=...

# API の識別子
AUTH0_AUDIENCE=...

認証フローの動作確認

実装が完了したら、ログイン URL(デフォルトでは /login)にアクセスし、Google アカウントを使った認証画面が表示されることを確認します。

auth0の認証画面

まとめ

今回、Laravel 11 で Auth0 を使用したユーザー認証を実装しました。

Auth0 を使うことで簡単に外部プロバイダーを介した認証を導入でき、柔軟かつ安全な認証フローを実現できます。

株式会社フォトラクションでは一緒に働く仲間を募集しています

www.wantedly.com

DroidKaigi2024にゴールドスポンサーとして参加しました。

Androidエンジニアの斎藤です。

昨年に引き続きDroidKaigiのゴールドスポンサーとして参加しました。

昨年参加した記事はこちら

kojichu.photoruction.com

引き続きと言いましたが私自身2024年に入社しましたので、初めての出展スタッフとして感じたことを執筆します。

Droidkaigiについて

まず、イベントの盛況具合に驚かされました。個人的に最後にオフラインで参加したのが2019年(?)だったと記憶しているのですが、その時以上に参加者の人数が多く出展ブースも増えたように感じます。

それ以上に熱気があるというか。Android熱がある人たちがこんなにもいるんだと思わされました。搬入についての思いを馳せざるを得ません。

HONDAブースにあった実車

HONDAのバイク

出展ブースの雰囲気

出展ブースをまわるスタンプラリーのおかげか多くの人に来ていただきました。

セッション中は一人で回せるくらいでしたが、セッションがない時間は一人で回らないくらい盛況でした。

ノベルティもいくつか用意しましたが、トートバッグは多くの人に褒めていただけました。

同じデザインのアロハシャツをチーム全員で着て参加しましたが同じく好評でした!

大盛況!!!

ノリノリなモバイルチームリーダー🕺

定番のアサイードリンクノベルティ🍇

好評だったノベルティバック✨

気になったセッション

いくつか気になったセッションがあったのですが、スタッフの兼ね合いもあって今回は1つだけ見ることができました。

  • オフライン・ファーストなアプリの実例: ガーナの農家アプリ
    • セッション内ではローカルDBにWriteするテーブルとReadするテーブルを分ける実装を紹介していました。フォトラクションもオフライン・ファーストなアプリで、同様の実装をしているので安心しました。
    • セッション内で遅延同期の方法としてWorkManagerを紹介していましたが、フォトラクションではまだ導入できていないので、早いところ導入したいと思いました。

そのほか気になってはいたが見ることができなかったセッションです。残念 😢

次回に向けて

出展スタッフとしては初めてだったので要領がわからなかった部分が多いのですが、次回はもう少し改善できるかもと感じたところです。

  • セッション参加は融通が効きそう。
    • 出展スタッフの負荷を多く見積りすぎてブースに張り付いてしまいましたが、うまく調整すればセッション参加は今回以上にできそうです。
  • アンケートボードをもう少しリッチにしたい。
    • アンケート記入から技術的な会話が始まることがあり、現場のリアルな声を聞く貴重な機会があったのでこれ自体は良かったです。ただ、簡易的なホワイトボード+付箋は他ブースに見劣りしていたと感じたので改善したいですね。
  • Android Developerの熱気で汗が止まらないので扇風機を持参したい。
    • 一方セッションルームはひんやりしていたので寒暖差には気をつけたい。
  • トークスクリプトをブラッシュアップしたい。
    • サービスの説明をするのに必死だったこともあり、サービス自体の魅力やその開発に携わる魅力みたいなプラスアルファを十分伝えることができなかった気がする。
株式会社フォトラクションでは一緒に働く仲間を募集しています

www.wantedly.com