Slide 1
Slide 1 text
for PHP Conference Japan 2020
PHP8時代の
Webアプリケーションフレームワークの話をしよう
2020年12⽉12⽇（⼟） 株式会社Nextat 中榮健⼆
Nextat Inc. 1
Slide 2
Slide 2 text
⾃⼰紹介
京都から配信しています
- 中榮健⼆ （なかえけんじ）
- twitter: @n_1215
- 株式会社Nextat 取締役
- Laravel/Unityでソーシャルゲーム開発
- → ここ最近はECサイト開発多め。Lambda + AppSync なども
Nextat Inc. 2
Slide 3
Slide 3 text
発表概要
1. はじめに
2. WebアプリケーションFWの仕組み
3. PHP8の新機能の活⽤
4. WebアプリケーションFWを取り巻く変化と課題
5. 参考にさせていただいたFW
6. 独⾃FW⾃作のすすめ
Nextat Inc. 3
Slide 4
Slide 4 text
1. はじめに
Nextat Inc. 4
Slide 5
Slide 5 text
当資料の"Webアプリケーション"の範囲
1リクエストに対して1レスポンスを同期で返すHTTPアプリケーション
サーバからのストリーミングや双⽅向通信はスコープ外
WebSocket、GraphQL Subscriptions、gRPC Streaming
触れたかったが25分では無理
本スライド中の⽤語の解説について
時間がないので⽤語の解説をふわっと⾶ばします
⼀部は他の素晴らしい発表に含まれているので該当の発表を列挙
Nextat Inc. 5
Slide 6
Slide 6 text
2. Webアプリケーションフレームワークの仕組み
Nextat Inc. 6
Slide 7
Slide 7 text
Webアプリケーション
Nextat Inc. 7
Slide 8
Slide 8 text
Webアプリケーション
⼊⼒：HTTPリクエスト
POST /path HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
this=is&request=body
出⼒：HTTPレスポンス
HTTP/1.1 200 OK
Host: example.com
Content-Type: text/plain;charset=UTF-8
X-Powered-By: PHP/8.0.0
This is response body
Nextat Inc. 8
Slide 9
Slide 9 text
ブラウザのデベロッパーツールから観察
最近のブラウザは簡単にHTTPメッセージの中⾝が⾒られるので便利
↓はChromeのデベロッパーツールのNetworkタブの様⼦
Nextat Inc. 9
Slide 10
Slide 10 text
PHPでのHTTPメッセージの処理
Slide 11
Slide 11 text
HTTPメッセージという単位で扱いたい
$_GET
や
$_POST
を直接扱うのは細かすぎる
HTTPという安定したプロトコルを抽象化の基礎にしたい
プログラミング⾔語⾮依存の概念
HTTPリクエストとHTTPレスポンスのクラスを作って抽象化
Nextat Inc. 11
Slide 12
Slide 12 text
Nextat Inc. 12
Slide 13
Slide 13 text
HTTPメッセージの実装
HTTPメッセージの実装がFW・プロジェクトごとに乱⽴していた
最近は２⼤勢⼒が⽬⽴つ
PSR-7 HTTP Messages
Symfony Http Foundation
Nextat Inc. 13
Slide 14
Slide 14 text
PSR-7 HTTP Message
PSR = PHPを使う上でオススメの規約やインターフェースの集まり（⾮公式）
HTTPメッセージ（HTTPリクエスト・レスポンス）のインターフェース
PSR-7に続きPSR-15、PSR-17などHTTPシリーズがある
採⽤例
Guzzle
Slim
CakePHP
Laminus Mezzio (旧Zend Expressive)
ReactPHP
新興のWeb FWはPSR-7/PSR-15対応を謳うものが多い
Nextat Inc. 14
Slide 15
Slide 15 text
PSRについて詳しく学ぶ
→ PSRで学ぶHTTP Webアプリケーションの実践
いつもはPSRの説明やコードをもう少し⼊れるのですが今回は安⼼して省けます！
ありがとうございます！
Nextat Inc. 15
Slide 16
Slide 16 text
Symfony HTTP Foundation
⼀番勢⼒の強い[要出典] HTTPメッセージ実装
Symfonyのコンポーネント
Laravelでも利⽤される（illuminate/http）
PSR-7より設計的には少し緩いが、取り扱いは便利
PSR-7互換のためのブリッジもある
https://symfony.com/doc/current/components/psr7.html
Nextat Inc. 16
Slide 17
Slide 17 text
注) HTTPメッセージに関連するサンプルコードについて
以下はPSR-7/15/17を意識したサンプルコードや疑似コード多め
他のHTTPメッセージの実装でもほぼ同様の考え⽅は可能
Nextat Inc. 17
Slide 18
Slide 18 text
改めて、Webアプリケーション
Nextat Inc. 18
Slide 19
Slide 19 text
HTTPリクエストハンドラ
Webアプリケーションの抽象化
PSR-15の例
interface RequestHandlerInterface
{
public function handle(ServerRequestInterface $request): ResponseInterface;
}
利⽤
$request = $requestCreator->createFromGlobal();
$handler = new MyRequestHandler();
$response = $handler->handle($request);
Nextat Inc. 19
Slide 20
Slide 20 text
なるほどいまいちわからん
Nextat Inc. 20
Slide 21
Slide 21 text
馴染み深い例
HTTPリクエストハンドラ ≒ コントローラのアクション
class GreetingController
{
public function hello(ServerRequestInterface $request) : ResponseInterface
{
$name = $request->getAttribute('name', 'world');
return new JsonResponse(['message' => "Hello, {$name}!"]);
}
}
Nextat Inc. 21
Slide 22
Slide 22 text
実際はもう少し簡略化されているケースが多い
//
ルータでパスパラメータが定義される
$router->get('/hello/{name}', [GreetingController::class, 'hello']);
class GreetingController
{
public function hello(string $name): array
{
return ['message' => "Hello, {$name}!"];
}
}
(HTTPリクエスト →) ルートパラメータ → 配列 (→ JSONレスポンス)
暗黙的な変換でリクエストハンドラ相当の処理が導出されている
Nextat Inc. 22
Slide 23
Slide 23 text
必須の部品1: Router
１つのリクエストハンドラ内で複数の機能の処理に分岐すると複雑
パスやHTTPメソッドを基準に機能ごとにリクエストハンドラを分けたい
$router->get('/hello/{name}', HelloHandler::class);
$router->get('/ping', PingHandler::class);
Router = HTTPのレイヤに特化した switch⽂
Router = HTTPのレイヤに特化した match式 （PHP8枠）
Nextat Inc. 23
Slide 24
Slide 24 text
match式で⾒る簡易Routerのイメージ
function router(ServerRequestInterface $request): Response
$path = $request->getUri()->getPath();
$response = match ($path) {
'hello' => $helloHandler->handle($request),
'ping' => $pingHandler->handle($request),
default => $notFoundHandler->handle($request)
}
return $response;
}
Routerで複数のHTTPリクエストハンドラをまとめる
Routerを再起的にHTTPリクエストハンドラとして扱うことが可能
Nextat Inc. 24
Slide 25
Slide 25 text
必須の部品2: HTTP Middleware
リクエストハンドラで同じ処理を何回も書きたくない
共通化するためのMiddleware
Nextat Inc. 25
Slide 26
Slide 26 text
コードで⾒ると
class MyMiddleware implements MiddlewareInterface {
public function process(
SeverRequestInterface $request,
RequestHandlerInterface $handler
): ResponseInterface {
//
前処理
// ...
//
ハンドラがリクエストを処理
$response = $handler->handle($request);
//
後処理
// ...
return $response;
}
}
Nextat Inc. 26
Slide 27
Slide 27 text
Middleware = リクエストハンドラ限定の インターセプター
リクエストハンドラの処理の前後に割り込んで共通処理を挟み込む
リクエストハンドラに対しAOP(Aspect Oriented Programming)を実現
発表後追記： koriyamさんより Middlewareはデザインパターンで⾔えば Chain
of Responsiblitiy ですねとのツッコミをいただいてます
Nextat Inc. 27
Slide 28
Slide 28 text
⼊出⼒に注⽬
Request Handler + Middleware = Request Handler
Nextat Inc. 28
Slide 29
Slide 29 text
合成が容易
リクエストハンドラにミドルウェアを複数被せたら再びリクエストハンドラに
Request Handler + Middleware * N = Request Handler
Nextat Inc. 29
Slide 30
Slide 30 text
Webアプリケーションフレームワークの共通機能
ルートごとのコントローラのアクションをまとめてWebアプリケーションを作る
つまり
HTTPリクエストハンドラ・ミドルウェアを合成して、
１つの⼤きなHTTPリクエストハンドラを作る
と⾔える
Nextat Inc. 30
Slide 31
Slide 31 text
リクエストハンドラの中⾝の設計
本資料では個別のリクエストハンドラの中⾝にはあまり触れません
中⾝は好きに作ってくださいというスタンス
この部分の設計もやりがいがあるが、Web FWの共通機能ではない
フルスタックフレームワーク
リクエストハンドラを扱う機能（先ほどまでの説明）
頻出機能を作るための再利⽤可能なコンポーネント群
CLIフレームワーク
etc.
※ 本資料で注⽬する ドメイン はHTTP層です
Nextat Inc. 31
Slide 32
Slide 32 text
Webアプリケーションの設計を学ぶ
→ PHP WEBアプリケーション設計⼊⾨――10年先を⾒据えて作る
https://speakerdeck.com/nrslib/introduction-to-web-application-design
Nextat Inc. 32
Slide 33
Slide 33 text
3. PHP8新機能の活⽤
Nextat Inc. 33
Slide 34
Slide 34 text
3-1. Constructor Property Promotion
Before
class PostController {
private PostService $service;
public function __construct(PostService $service)
{
$this->service = $servuce;
}
public function show(int $postId): JsonResponse
{
$post = $this->service->find($postId);
//
略
}
}
Nextat Inc. 34
Slide 35
Slide 35 text
After
class PostController {
public function __construct(PostService $service) {}
public function show(int $postId): JsonResponse
{
$post = $this->service->find($postId);
//
略
}
}
Nextat Inc. 35
Slide 36
Slide 36 text
⼩クラス主義の後押し
コンストラクタから依存するオブジェクトを注⼊するコードが短くなる
⼩さな部品を組み合わせてより複雑な機能を作る
継承より移譲
⼩クラスが流⾏るのでは？
例）コントローラ単位のクラス→アクション/リクエストハンドラ単位に
Controllersディレクトリ → Handlersディレクトリ
Nextat Inc. 36
Slide 37
Slide 37 text
⼩クラス主義の難点
AがBに依存していて、BがCに依存していて、CがDに依存していて……
⼈の⼿で⽣成コードを利⽤するすべての箇所で書くのは⼤変
$handler = new GreetingHandler(
new GreetingService(
new RdbGreetingRepository(
new DatabaseConnection(
new Pdo($dsn)
)
)
)
);
Nextat Inc. 37
Slide 38
Slide 38 text
DIコンテナ
⽣成⽅法を登録しておけば、依存関係を解決したオブジェクトを作ってくれる
インターフェースに依存している部分は登録を変更するだけで差し替えられる
DIコンテナは⼩クラス主義の強い味⽅
//
⽣成⽅法の登録
$container->bind(GreetingRepositoryInterface::class)
->to(RdbGreetingRepository::class);
//
（略）
//
オブジェクトの利⽤側は⽣成⽅法を気にしない
$handler = $container->get(GreetingHandler::class);
Nextat Inc. 38
Slide 39
Slide 39 text
DIコンテナについて詳しく学ぶ
→ CakePHPで学ぶDIコンテナ
https://speakerdeck.com/itosho525/learn-a-di-container-through-cakephp
説明するととても⻑くなるので助かります！
Nextat Inc. 39
Slide 40
Slide 40 text
3-2. Attributes
クラスやメソッド、プロパティ、引数などにメタ情報を付加する機能
PHP8より前はコメント内の記述で代⽤していた
正式に採⽤されたことで⼤⼿を振って使える
いわゆるデコレータとは違うので注意
あくまで⽬印をつけるだけ
Nextat Inc. 40
Slide 41
Slide 41 text
Attributesのシンタックス
#[
ORM\Entity,
ORM\Table("user")
]
class User
{
#[ORM\Id, ORM\Column("integer"), ORM\GeneratedValue]
private $id;
#[ORM\Column("string", ORM\Column::UNIQUE)]
#[Assert\Email(["message" => "The email '{{ value }}' is not a valid email."])]
private $email;
}
https://wiki.php.net/rfc/shorter_attribute_syntax_change
Nextat Inc. 41
Slide 42
Slide 42 text
AOP (Aspect Oriented Programming)に有⽤
Attributesのメタ情報を⼿掛かりにして対応した処理を挟み込む
Middlewareを使わずとも横断的な処理を挟むことができるようになる
HTTPに関係ない横断処理に有⽤
参考：Ray.Aop
https://github.com/ray-di/Ray.Aop
Nextat Inc. 42
Slide 43
Slide 43 text
Web FWへのAttributes活⽤例
デコレータ/アノテーションを機能として持つ⾔語界隈でよく⾒る例
ルートの定義をリクエストハンドラのすぐ側で⾏う
リクエストパラメータやレスポンスの暗黙的な変換を明⽰的に⽰すDSL
#[RequireLoginMiddleware]
class ShowPostHandler
{
#[Route\Get('posts/{postId}')]
#[JsonResponse]
#[Cache]
public function handle(
#[RouteParam] int $postId
): array {
return Post::find($postId)->toArray();
}
}
Nextat Inc. 43
Slide 44
Slide 44 text
AOPについて詳しく（？）学ぶ
→ PHP WEBアプリケーション設計⼊⾨――10年先を⾒据えて作る
https://speakerdeck.com/nrslib/introduction-to-web-application-design
"横断的関⼼毎" という項⽬があったのでおそらく触れられると思います
→ 発表後追記： 残念ながらMiddlewareの話でした
Nextat Inc. 44
Slide 45
Slide 45 text
3-3. Union Typesなど型に関する機能
Union Types
Static return type
（PHP7.4ですが） Typed Properties
静的解析ブーム
IDEの静的解析の強化
PHPStan, Psalmなど静的解析ツールの進化
静的解析フレンドリーなFWも増えるはず
Nextat Inc. 45
Slide 46
Slide 46 text
静的解析について詳しく学ぶ
→ レガシープロジェクトで、メタプログラミングを使ったPHPStan静的解析
レベル上げ
https://speakerdeck.com/komtaki/regasipuroziekutode-
metapuroguraminguwoshi-tuta-phpstanjing-de-jie-xi-levelshang-ge-php-
conference-2020
→ 効果的な静的解析のCI導⼊パターンを求めて
https://speakerdeck.com/oogfranz/great-static-analysis-with-ci
→ (LT) 静的解析から始める負債コード解消
静的解析の⼈気が伺えますね
Nextat Inc. 46
Slide 47
Slide 47 text
ここまでのまとめ
Webアプリケーションフレームワークの備える共通機能や概念を説明
PHPのWebアプリケーションを考えるための下地が整った
なんとなくこう共通化すると便利 → より洗練された抽象化へ
PHP8の機能の活⽤も夢が広がる
Nextat Inc. 47
Slide 48
Slide 48 text
4. WebアプリケーションFWを取り巻く変化と課題
注）以下独断と偏⾒成分が増えます
Nextat Inc. 48
Slide 49
Slide 49 text
フレームワークの制約・個性
共通の機能以外の機能や制約が個性やアピールポイントになる
REST・ハイパーメディア
⾼速開発
設定より規約
使い⼼地の揃ったコンポーネント群
etc...
現状の課題からも新しい制約や個性が⽣まれるはず
PHPとWebアプリケーションを取り巻く変化を⾒ていこう
Nextat Inc. 49
Slide 50
Slide 50 text
4-1. 様々なデプロイ先とランタイム
PHP-FPM以外の選択肢
Swoole https://www.swoole.co.uk/
RoadRunner https://roadrunner.dev/
ReactPHP https://reactphp.org/
Nextat Inc. 50
Slide 51
Slide 51 text
FaaSでも⾛るPHP
LambdaのPHPランタイム（カスタムランタイム）
拡張を独⾃で追加するのはハードルが⾼かった
が、最近コンテナのサポートが⼊った
Google Cloud FunctionsのPHP7.4ランタイム（まだアルファ）
https://github.com/GoogleCloudPlatform/functions-framework-php
Vercel
https://calebporzio.com/easy-free-serverless-laravel-with-vercel
Cloudflare Workers
bable-preset-phpでPHPソースをJSに変換
https://github.com/cloudflare/php-worker-hello-world
Nextat Inc. 51
Slide 52
Slide 52 text
Write Once, Deploy Anyware （したい）
FaaSへのデプロイの⾃動化は⼤変
コードだけ書いたら最⼩限の設定でいい感じにしてほしい
Serverless Framework
https://www.serverless.com/https://www.serverless.com/
Bref https://bref.sh/
Laravel Vapor https://vapor.laravel.com/
我々のコードとインフラとのつなぎ⽬をカバーしてくれるフレームワークに期待
Nextat Inc. 52
Slide 53
Slide 53 text
デプロイ先やFaaSについて詳しく学ぶ
→ GCPとPHP
https://speakerdeck.com/gamu1012/gcptophp-php-conference-japan-2020
→ PHP on Kubernetes
https://speakerdeck.com/cwozaki/php-on-kubernetes-php-conference-2020-
re-born-number-phpcon
→ (LT) PHP8 on AWS lambda
Nextat Inc. 53
Slide 54
Slide 54 text
4-2. Webフロントエンドや他サービスとの連携
PHPのサーバ側アプリケーション１つだけでは完結しない傾向
WebフロントエンドのSPA
SaaS、mBaaSの活⽤
チームや機能に合わせたマイクロサービス化
Nextat Inc. 54
Slide 55
Slide 55 text
Webフロントエンドとの連携を例に考える
Q. 最⾼の設計のバックエンドと最⾼の設計のWebフロント
エンドを組み合わせれば、全体として最⾼のシステムになる
だろうか？
A. そうとは限らない
Nextat Inc. 55
Slide 56
Slide 56 text
局所最適化、統合コスト
バックエンドとフロントエンドで整合性が取れない
別々に作って繋げようとして初めてうまく繋がらないことがわかる
ボイラープレートが増え、作業量が増える
本質的ではないミスも出やすい
Nextat Inc. 56
Slide 57
Slide 57 text
システムのつなぎ⽬を上⼿く作る重要性
システム間のインターフェース
インターフェースがあれば、⼀旦中⾝の詳細を忘れて⼀段階抽象化した思考がで
きる
⼈間が⽊の葉を⾒ながら森も⾒るのは⼤変
APIファースト
Nextat Inc. 57
Slide 58
Slide 58 text
「定義のないAPIなんて
ツメが折れたLANケーブルみたいなもんでしょ」
Nextat Inc. 58
Slide 59
Slide 59 text
アプローチ１： API定義からコードの⾃動⽣成
⾃動⽣成による省⼒化・ミス防⽌
クライアント側はほぼ⾃動⽣成可能
サーバ側はレスポンスの型を⾃動⽣成し、静的に解析することも可能
API定義にサーバ側の実装が従っているかどうかをテスト
⾔語⾮依存のAPI定義記述⼿法、IDL
OpenAPI https://swagger.io/specification/
GraphQL https://graphql.org/
gRPC https://grpc.io/
AsyncAPI（OpenAPIの⾮同期版）https://www.asyncapi.com/
CNCF CloudEvents（イベント通知の標準化）https://cloudevents.io/
Nextat Inc. 59
Slide 60
Slide 60 text
アプローチ2: サーバとクライアントの垣根をなくす
「JS/TSでバックエンドのAPIも書いてしまえば良いのでは？」
フロントエンドメインのFWだが サーバ側のAPIも書ける例
Next.js API Routes
https://nextjs.org/docs/api-routes/introduction
Nuxt.js serverMiddleware
https://ja.nuxtjs.org/docs/2.x/configuration-glossary/configuration-
servermiddleware/
Nextat Inc. 60
Slide 61
Slide 61 text
コードファーストなAPI定義
API定義からのコード⽣成は⽣成し直す⼿間がある
バックエンドとフロントエンドが同じ⾔語ならコードで型定義を主して使いまわ
せる
サーバ・クライアントの⾔語の"⼤統⼀"、アイソモーフィック
frourio https://github.com/frouriojs/frourio
"One TypeScript"
protobuf-net.Grpc (C#、 .NET)
https://github.com/protobuf-net/protobuf-net.Grpc
MagicOnion（C#、 .NET Core/Unity） gRPC + MessagePack
https://github.com/Cysharp/MagicOnion
Nextat Inc. 61
Slide 62
Slide 62 text
protobuf-net.Grpcの例（アノテーションを活⽤）
[DataContract]
public class User
{
[DataMember(Order = 1)]
public uint id { get; set; }
[DataMember(Order = 2)]
public string name { get; set; }
}
対応するgRPCのメッセージ
message User {
uint32 id = 1;
string name = 2;
}
Nextat Inc. 62
Slide 63
Slide 63 text
「バックエンドの⾔語でフロントを書ければ良いのでは？」
JavaScriptを書かずに済ませられるなら済ませたいという気持ち
Phoenix LiveView (Elixir)
https://dockyard.com/blog/2018/12/12/phoenix-liveview-interactive-
real-time-apps-no-need-to-write-javascript
Laravel Livewire
https://calebporzio.com/proof-of-concept-phoenix-liveview-for-
laravel/
Phoenix LiveViewをインスパイア
Laravel JetstreamでLaravel公式の仲間⼊り
余談ですが、Laravelはエコシステムが育ってきた感じがありますね
Nextat Inc. 63
Slide 64
Slide 64 text
システム間をスムーズに繋ぐためのアプローチもいろ
いろあって⾯⽩い
Nextat Inc. 64
Slide 65
Slide 65 text
OpenAPIについて詳しく学ぶ
→ ゼロベースから Laravel を⽤いた API 実装オートメーション
https://speakerdeck.com/memory1994/zerobesukara-laravel-woyong-ita-api-
shi-zhuang-otomesiyon
GraphQLについて詳しく学ぶ
→ Laravel + Lighthouseで始める低コストなGraphQL⼊⾨
https://speakerdeck.com/d_endo/laravel-plus-lighthousedeshi-merudi-
kosutonagraphqlru-men
Nextat Inc. 65
Slide 66
Slide 66 text
gRPCについて詳しく（？）学ぶ
→ PHP8はISUCONへの扉を開く鍵となるか
https://docs.google.com/presentation/d/1BgaSPWa5NJTAIC__8kRRx3lzxxim
KNvTcxuNWnA0Td0/edit
■
お話しないこと
-
パフォーマンス以外の話
- PHP
のgRPC
利⽤について ←
アッ
→ 発表後追記： 触れられてませんでした
Nextat Inc. 66
Slide 67
Slide 67 text
SPA、APIについて詳しく学ぶ
→ SPAのAPI開発の「やりづらさ」をDDDとオブジェクト指向の発想で解決
する
https://tech.quartetcom.co.jp/2020/12/11/phpcon2020-pre
→ Laravelで運⽤しているサービスをNuxt.jsにリプレイスする
https://speakerdeck.com/kubotak/laraveldeyun-yong-siteirusabisuwo-nuxt-
dot-jsniripureisusuru
Nextat Inc. 67
Slide 68
Slide 68 text
メッセージ駆動、マイクロサービスについて詳しく学ぶ
→ 事業のスケールアウトを⽀えるPHPで作る分散アーキテクチャ
https://speakerdeck.com/ytake/shi-ye-falsesukeruautowozhi-eru-phpdezuo-
rufen-san-akitekutiya
→ Service communication re:Born
Nextat Inc. 68
Slide 69
Slide 69 text
5. 独⾃フレームワーク⾃作のすすめ
Nextat Inc. 69
Slide 70
Slide 70 text
⾃作のすゝめ
開発⼿法の変化や課題があってチャレンジしがいがある
今使っているWeb FWへの理解を深められる
⾃作・⾞輪の再発明は最⾼の勉強⽅法
最初から壮⼤なものを作るのは⼤変
⼩さく始める
完全に0から作る必要はない
既存のコンポーネントを組み合わせる
薄いFWに後付けで好みの改造を施し開発プロジェクトの効率を上げる
Nextat Inc. 70
Slide 71
Slide 71 text
今は有名なあのフレームワークも
開発当初はオレオレ独⾃フレームワークだった
Nextat Inc. 71
Slide 72
Slide 72 text
誰かのオレオレフレームワークが
PHPの世界を変えていく
Nextat Inc. 72
Slide 73
Slide 73 text
まとめ
PHPのWeb FWの設計を考えるための下地となる概念が整った
PHP8の新機能もFWの実装を後押しする
Webアプリ開発の課題を解決する新しいFWに期待
例1. 様々なターゲットへのデプロイを楽にしてくれるFW
例2. システム同⼠の繋ぎ⽬をケアしてくれるFW
⼩さな部品を組み合わせてサービス全体を作り上げていく。APIは⼤事
独⾃フレームワーク製作を始めるなら今でしょ！
Nextat Inc. 73
Slide 74
Slide 74 text
PR: We're hiring!
株式会社 Nextat
受託開発
業務システム、ECサイト、ソシャゲ
京都・東京メインで求⼈しています
私も⽉1くらいで東京に通ってます
設計の話に付き合ってくれる⽅⼤歓迎！
Nextat Inc. 74
Slide 75
Slide 75 text
ご清聴ありがとうございました
Nextat Inc. 75
Slide 76
Slide 76 text
本資料の参考にさせていただいたフレームワーク
および参考にした点のメモ
Nextat Inc. 76
Slide 77
Slide 77 text
参考フレームワーク（PHP）
API Platform （REST、GraphQL）https://api-platform.com/
Siler （GraphQL、Swoole）https://github.com/leocavalcante/siler
Hyperf （Swoole、coroutine）https://hyperf.wiki/2.0/
Symlex （RoadRunner、Symfony component）https://symlex.org/
Swoft (Swoole、coroutine) http://en.swoft.org/
Spiral Framework (PHP/Go、RoadRunner) https://spiral.dev/
Bref (Lambda) https://bref.sh/
Nextat Inc. 77
Slide 78
Slide 78 text
参考フレームワーク（PHP）
Igni (PSR、Swoole) https://github.com/igniphp/framework
Comet (Slim + Workerman) https://github.com/gotzmann/comet
BEAR.Sundy (REST、AOP) https://bearsunday.github.io
Laravel (Fullstack、Symfony component)https://laravel.com/
CakePHP （規約、PSR）https://cakephp.org
Laminas Mezzio (Middleware) https://docs.mezzio.dev/mezzio/
Lighthouse (Laravel + GraphQL) https://lighthouse-php.com/
Railt (Laravel + GraphQL) https://github.com/railt/railt
Nextat Inc. 78
Slide 79
Slide 79 text
参考フレームワーク（他⾔語）
Quarkus （Java、GraalVM対応、コンテナ）https://quarkus.io/
Micronaut （Java、GraalVM対応、コンテナ）https://micronaut.io/
Spring WebFlux（Java、リアクティブプログラミング）
https://spring.pleiades.io/spring-
framework/docs/current/reference/html/web-reactive.html
Rocket （Rust、 Extractor、Responders）https://rocket.rs/
Blitz.js （JavaScript、Next.js + ORM、isomorphic）https://blitzjs.com/
NestJS (TypeScript、Fullstack、Decorator) https://nestjs.com/
frourio (TypeScript、One TypeScript) https://frourio.io/
Nextat Inc. 79
Slide 80
Slide 80 text
参考フレームワーク（他⾔語）
Ktor（Kotlin、Annotaion、DSL）https://ktor.io/
Servant （Haskell、型安全なAPI定義）https://www.servant.dev/
Responder（Python、ASGI、 OpenAPIスキーマの⽣成）
https://responder.kennethreitz.org/en/latest/
Alosaur（Deno、Decorator）https://github.com/alosaur/alosaur
midway（JavaScript、serverless）https://midwayjs.org/
Nextat Inc. 80