Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
『eg-r2』のご紹介
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
katzumi
December 23, 2024
Technology
30
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
『eg-r2』のご紹介
PHPカンファレンス2024 アンカンファレンス
https://phpcon.php.gr.jp/2024/
katzumi
December 23, 2024
More Decks by katzumi
See All by katzumi
設計原則、アーキテクチャパターン、アーキテクチャスタイルの違いって何?いつどう向き合ったらいいの?を考えてみる
katzumi
0
220
runn開発者会議福岡2024
katzumi
0
36
リリース戦略を支えるCI/CDパ イプライン
katzumi
0
29
APIテストでもカバレッジ測定 したい!
katzumi
0
26
Slidevのテンプレートリポジトリについて
katzumi
0
160
OSSへの感謝を伝える
katzumi
0
660
モブワークを進化させていった話
katzumi
0
500
ActiveRecordパターンの呪縛を学びほぐして挑むクリーンアーキテクチャへの入り口
katzumi
0
64
実装と乖離させないスキーマ駆動開発フロー / OpenAPI Laravel編
katzumi
0
290
Other Decks in Technology
See All in Technology
データ組織の転換期 一足飛びしない段階的戦略
leveragestech
PRO
0
130
AI エージェント時代のデジタルアイデンティティ
fujie
2
1.3k
データ活用研修 データマネジメント【MIXI 26新卒技術研修】
mixi_engineers
PRO
4
840
AI工学特論: MLOps・継続的評価
asei
11
3.1k
AIがコードを書く時代、人間は何を保証するのか———馬場さんと考える、開発者に求められる新しい責任と価値 - TECH PLAY
netmarkjp
0
890
AIで楽になるはずが、なぜ疲れる?
kinopeee
0
150
運用を犠牲にせずコストを制御し事業成長を支える B2B SaaS ID管理基盤におけるS3 Tableのログストレージ活用
kaminashi
1
130
なぜ、あなたのAPIは使われないのか? AX時代の設計原則、ガードレール、運用体制
yokawasa
1
870
コンポーネント名には何を含めるべきなのか? / what-should-be-included-in-component-names
airrnot1106
0
200
検索技術知識0のエンジニアが広告検索システムを内製化して運用するまで
lycorptech_jp
PRO
0
180
Atlassian Cloudサポート業務でのAIエージェント活用事例
smt7174
0
180
もう一度考える SRE チームの作り方・育て方 / Rethinking SRE #1: Building and Growing SRE Teams
rrreeeyyy
1
290
Featured
See All Featured
Typedesign – Prime Four
hannesfritz
42
3.1k
The B2B funnel & how to create a winning content strategy
katarinadahlin
PRO
1
450
Believing is Seeing
oripsolob
1
180
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.8k
Producing Creativity
orderedlist
PRO
348
40k
ラッコキーワード サービス紹介資料
rakko
1
4.1M
Navigating Team Friction
lara
192
16k
First, design no harm
axbom
PRO
2
1.2k
Data-driven link building: lessons from a $708K investment (BrightonSEO talk)
szymonslowik
1
1.2k
Why Your Marketing Sucks and What You Can Do About It - Sophie Logan
marketingsoph
0
340
GraphQLの誤解/rethinking-graphql
sonatard
75
12k
The Power of CSS Pseudo Elements
geoffreycrofte
82
6.5k
Transcript
『eg-r2 』のご紹介 Press Space for next page PHP カンファレンス 2024
Dec 22, 2024. v0.0.2 @katzumi( かつみ)
自己紹介 「障害のない社会をつくる」をビジョンに掲げている「LITALICO 」という会社に所属しています 以下のアカウントで活動しています。 katzchum k2tzumi katzumi katzumi (かつみ)と申します。
アドカレがプチバズしました🎉 初めての 100 ブクマオーバー https://b.hatena.ne.jp/site/zenn.dev/litalico
本日のお題 OSS 化したツールの紹介をします!
ここから先のスライドについて 社内イベントで発表した非エンジニア向けのスライドになっています。
eg-r2 プレリリース 法改正リリース後に社内のみ先行公開していました
祝!オープンソース化! 🎉 たぶん LITALICO 初
オープンソースソフトウェアとは? wikipedia より What is OSS ? オープンソースソフトウェア(Open Source Software
、略称: OSS )とは、利用者の目的を問わずソースコードを使用、調査、再 利用、修正、拡張、再配布が可能なソフトウェアの総称である。 “
packagist にも公開されています composer require litalico-engineering/eg-r2 で直ぐに使えます。 https://packagist.org/packages/litalico-engineering/eg-r2 Packagist は Composer
のメインリポジトリです。 Composer でインストール可能な公開 PHP パッケージが集約されています。 Packagist には、たくさんのパッケージが登録されています。 これらのパッケージは他の開発者が作った便利な部品で、プログラマーは自分のプロジェクトに簡単に 取り込むことができます。 MEMO
eg-r2 とは? 2 つのことを簡単(Easy) にすることを目的としています Easy request validation and route
generation from open API specifications
eg-r2 とは? 2 つのことを簡単(Easy) にすることを目的としています 1. リクエストバリデーション Easy request validation
and route generation from open API specifications
eg-r2 とは? 2 つのことを簡単(Easy) にすることを目的としています 1. リクエストバリデーション 2. ルーティング設定 Easy
request validation and route generation from open API specifications
前提 PHP8.2 以上 PHP Attributes で API Spec を記述する為 Laravel9.0
以上 最新バージョン(version1.0.0) 以降は 11.0 以上 swagger-php で API 仕様書を OpenAPI V3 形式で記述 require
リクエストのバリデーション自動生成 OpenAPI でスキーマ定義しておけば、バリデーションが自動生成されます! Easy request validation リクエストのバリデーションとは? 例えば、オンラインショッピングでお買い物をする時に、名前や住所、クレジットカード番号等の入 力内容を「リクエスト」と言い その時に、入力内容(リクエスト)が正しい形式であるか、間違いや漏
れがないかを確認することを「バリデーション」といいます。 具体的には、次のようなことをチェックします。 1. 必須項目の確認: 名前や住所など、必ず入力しなければならない情報がちゃんと入力されているかを 確認します。 2. 形式の確認: メールアドレスが「@ 」を含んでいるか、クレジットカード番号が数字のみで構成され ているかなど、特定の形式に合っているかをチェックします。 3. 範囲の確認: 年齢や金額など、入力された値が決められた範囲内にあるかを確認します。 MEMO
As-is 別途 API 仕様書を記述する必要があります こんな感じで FormRequest のクラス定義していますよね? /** * @property
int $age * @property string $name * @property bool $is_active */ class MyFormRequest extends FormRequest { public function rules() { return [ 'age' => 'required|integer', 'name' => 'required|string', 'is_active' => 'required|boolean', ]; } }
As-is 別途 API 仕様書を記述する必要があります こんな感じで FormRequest のクラス定義していますよね? /** * @property
int $age * @property string $name * @property bool $is_active */ class MyFormRequest extends FormRequest { public function rules() { return [ 'age' => 'required|integer', 'name' => 'required|string', 'is_active' => 'required|boolean', ]; } }
To-be Trait を追加するだけ!その他の記述不要 リクエストパラメータを型安全で扱えます! こんな感じで FormRequest に OpenAPI を Spec
を Attribute を記述するだけ! #[Schema(title: 'My request', required:['age', 'name', 'is_active'])] class MyFormRequest extends FormRequest { use RequestRuleGeneratorTrait, FormRequestPropertyHandlerTrait; #[Property(property: 'age', type: 'integer', format: 'int64')] public int $age; #[Property(property: 'name', type: 'string')] public string $name; #[Property(property: 'is_active', type: 'boolean')] public boolean $is_active; // roules メソッドはtrait で自動生成しているので不要 }
To-be Trait を追加するだけ!その他の記述不要 リクエストパラメータを型安全で扱えます! こんな感じで FormRequest に OpenAPI を Spec
を Attribute を記述するだけ! #[Schema(title: 'My request', required:['age', 'name', 'is_active'])] class MyFormRequest extends FormRequest { use RequestRuleGeneratorTrait, FormRequestPropertyHandlerTrait; #[Property(property: 'age', type: 'integer', format: 'int64')] public int $age; #[Property(property: 'name', type: 'string')] public string $name; #[Property(property: 'is_active', type: 'boolean')] public boolean $is_active; // roules メソッドはtrait で自動生成しているので不要 }
何が嬉しいのか? API 仕様書と実装の乖離を発生させない! そもそも同じことを 2 回書く必要がなくなる 開発の手数が減り、気になりポイントも減る 全体の記述量も減るのでは? eg-r2 の狙い
ルーティング設定の自動化 OpenAPI でスキーマ定義しておけば、ルーティング設定が半自動化されます! Easy route generation ルーティングとは? インターネット上で誰かが何かを求めてきた時に、そのリクエストをどこに送るかを決めることを 「ルーティング」といいます。 具体的な例を挙げると
1. ホームページ: お客様が「ホームページを見たい」とリクエストした場合、そのリクエストをホーム ページの担当部署に送ります。 2. 商品ページ お客様が「商品ページを見たい」とリクエストした場合、そのリクエストを商品ページの 担当部署に送ります。 3. 注文ページ: お客様が「注文したい」とリクエストした場合、そのリクエストを注文ページの担当部 署に送ります。 MEMO
ルーティング設定の自動化 コマンド一発でルーティングの自動生成 php artisan eg-r2:generate-route Easy route generation /** *
This file is auto-generated. */ declare(strict_types=1); Route::as('api')->group(static function (): void { Route::controller('App\Http\Controllers\Pet')->group(static function (): void { Route::post('/pet', 'addPet'); Route::put('/pet', 'updatePet'); Route::get('/pet/findByStatus', 'findPetsByStatus'); Route::post('/pet/{petId}', 'updatePetWithForm'); Route::delete('/pet/{petId}', 'deletePet'); Route::post('/pet/{petId}/uploadImage', 'uploadFile'); }); Route::controller('App\Http\Controllers\Store')->group(static function (): void { Route::get('/store', 'getInventory'); Route::post('/store/order', 'placeOrder'); Route::get('/store/order/{orderId}', 'getOrderById');
Route::delete('/store/order/{orderId}', 'deleteOrder'); }); }); なぜ eg-r2 を作ったのか? API 仕様書の品質を高めるため! API
仕様書の品質が悪いと手戻りが発生してしまう。サーバー側とクライアント側共に API 仕様の見直しで実装との乖離を発生させない 法解釈が違ったら直さないといけなくなる API 仕様書を先に公開して実装するため 各プロダクトと並行で開発する 。API の完成を待っていたら開発が間に合わない 1. スキーマ駆動開発といいます ↩︎ 全ては法改正を爆速に対応できるシステムを構築するため [1]
どうなったか? 多数の API を高品質且つ爆速で構築 法改正を乗り越えることができた🎉 200 弱の API が eg-r2
によって作成 1 つの API で 100 弱のパラメータが存在 法改正時に 80 の API を追加 短期間にコピペで量産することもできる eg-r2 の効果
なぜ eg-r2 をオープンソース化したのか? 様々なユースケースに対応させるため 他プロジェクトでの個別な要望にも対応できるように機能追加をしていきたい フィードバックサイクルを回すため スキーマ駆動開発の在り方をディスカッションしたい スキーマが先か?コードが先か?の問題を提起したい OSS 化の狙い
今後について 対応ユースケースの拡大 ドックフーディングしてくれる方募集中です 社内外での発信し、認知拡大 eg-r2 の発展について
最後に We’re contributing. プロジェクトに貢献してくれる方、絶賛募集中です
Link eg-r2 プロジェクトリポジトリ eg-r2-example サンプルリポジトリ 頑張らないスキーマ駆動開発を支える『eg-r2 』を公開しました
ご清聴ありがとうございました