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
katzumi
December 23, 2024
Technology
29
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
32
リリース戦略を支えるCI/CDパ イプライン
katzumi
0
27
APIテストでもカバレッジ測定 したい!
katzumi
0
24
Slidevのテンプレートリポジトリについて
katzumi
0
150
OSSへの感謝を伝える
katzumi
0
650
モブワークを進化させていった話
katzumi
0
500
ActiveRecordパターンの呪縛を学びほぐして挑むクリーンアーキテクチャへの入り口
katzumi
0
62
実装と乖離させないスキーマ駆動開発フロー / OpenAPI Laravel編
katzumi
0
290
Other Decks in Technology
See All in Technology
インフラ寄りSREでも 開発に踏み出せる〜境界を越えてユーザー体験に向き合いたい〜
sansantech
PRO
0
1.3k
FinOps X 2026 Recap from Engineer Side #JapanFinOps
chacco38
0
260
Terraform共通モジュールをチーム横断で“変えられる”運用へ ― リリースと適用の分離
kekke_n
0
770
AWS Blocks を触ってみた/first-tach-aws-blocks
fossamagna
2
150
スタートアップにおけるアジャイルの実践について #shibuyagile
murabayashi
3
2.1k
証券システムを10年Scalaで作り続けるということ - 関数型まつり2026
krrrr38
3
700
SRE歴2ヶ月でも開発6年の知見を活かして、チームで止まっていた環境改善を前に進めた話
a_ono
1
210
金融の未来を考える / Thinking About the Future of Finance
ks91
PRO
0
160
キャリアの中で本を作る / Making a Book During Your Career
ak1210
0
100
オブザーバビリティ、本当に活用できてる? 〜API連携×生成AIで成熟度を自動評価〜
dmmsre
0
1.1k
Control Planeで育てるBtoB SaaSの認証基盤 - SRE NEXT 2026
pokohide
1
570
SRE依存からの脱却 運用を開 発チームへ移す、 フルサイ クル開 発体制の実践
joooee0000
0
800
Featured
See All Featured
Why You Should Never Use an ORM
jnunemaker
PRO
61
9.9k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
10
1.2k
[RailsConf 2023] Rails as a piece of cake
palkan
59
6.7k
What the history of the web can teach us about the future of AI
inesmontani
PRO
1
630
The Art of Programming - Codeland 2020
erikaheidi
57
14k
Unsuck your backbone
ammeep
672
58k
Design of three-dimensional binary manipulators for pick-and-place task avoiding obstacles (IECON2024)
konakalab
0
480
Darren the Foodie - Storyboard
khoart
PRO
3
3.4k
Leading Effective Engineering Teams in the AI Era
addyosmani
9
2.1k
Imperfection Machines: The Place of Print at Facebook
scottboms
270
14k
SEOcharity - Dark patterns in SEO and UX: How to avoid them and build a more ethical web
sarafernandez
0
220
Product Roadmaps are Hard
iamctodd
55
12k
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 』を公開しました
ご清聴ありがとうございました