PHP8時代のWebアプリケーションフレームワークの話をしよう

2020/12/12 PHPカンファレンス2020の登壇資料です

Transcript

1. for PHP Conference Japan 2020 PHP8時代の Webアプリケーションフレームワークの話をしよう 2020年12⽉12⽇（⼟） 株式会社Nextat 中榮健⼆ Nextat Inc. 1
2. ⾃⼰紹介 京都から配信しています - 中榮健⼆ （なかえけんじ） - twitter: @n_1215  - 株式会社Nextat 取締役 - Laravel/Unityでソーシャルゲーム開発 - → ここ最近はECサイト開発多め。Lambda + AppSync なども Nextat Inc. 2
3. 発表概要 1. はじめに 2. WebアプリケーションFWの仕組み 3. PHP8の新機能の活⽤ 4. WebアプリケーションFWを取り巻く変化と課題 5. 参考にさせていただいたFW 6. 独⾃FW⾃作のすすめ Nextat Inc. 3
4. 1. はじめに Nextat Inc. 4
5. 当資料の"Webアプリケーション"の範囲 1リクエストに対して1レスポンスを同期で返すHTTPアプリケーション サーバからのストリーミングや双⽅向通信はスコープ外 WebSocket、GraphQL Subscriptions、gRPC Streaming 触れたかったが25分では無理 本スライド中の⽤語の解説について 時間がないので⽤語の解説をふわっと⾶ばします ⼀部は他の素晴らしい発表に含まれているので該当の発表を列挙 Nextat Inc. 5
6. 2. Webアプリケーションフレームワークの仕組み Nextat Inc. 6
7. Webアプリケーション Nextat Inc. 7
8. 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
9. ブラウザのデベロッパーツールから観察 最近のブラウザは簡単にHTTPメッセージの中⾝が⾒られるので便利 ↓はChromeのデベロッパーツールのNetworkタブの様⼦ Nextat Inc. 9
10. PHPでのHTTPメッセージの処理 <?php header('X-Powered-By: NonFramework/0.1'); $name = $_GET["name"] ?? 'World'; echo 'Hello ' . htmlspecialchars($name, ENT_QUOTES) . '!'; スーパーグローバル( $_GET , $_POST ...)に⼊った値からHTTPリクエストの値が 取れる echoやheader()関数でHTTPレスポンスを組み⽴てる とてもお⼿軽だが…… Nextat Inc. 10
11. HTTPメッセージという単位で扱いたい $_GET や $_POST を直接扱うのは細かすぎる HTTPという安定したプロトコルを抽象化の基礎にしたい プログラミング⾔語⾮依存の概念 HTTPリクエストとHTTPレスポンスのクラスを作って抽象化 Nextat Inc. 11
12. Nextat Inc. 12
13. HTTPメッセージの実装 HTTPメッセージの実装がFW・プロジェクトごとに乱⽴していた 最近は２⼤勢⼒が⽬⽴つ PSR-7 HTTP Messages Symfony Http Foundation Nextat Inc. 13
14. 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
15. PSRについて詳しく学ぶ → PSRで学ぶHTTP Webアプリケーションの実践 いつもはPSRの説明やコードをもう少し⼊れるのですが今回は安⼼して省けます！ ありがとうございます！ Nextat Inc. 15
16. Symfony HTTP Foundation ⼀番勢⼒の強い[要出典] HTTPメッセージ実装 Symfonyのコンポーネント Laravelでも利⽤される（illuminate/http） PSR-7より設計的には少し緩いが、取り扱いは便利 PSR-7互換のためのブリッジもある https://symfony.com/doc/current/components/psr7.html Nextat Inc. 16
17. 注) HTTPメッセージに関連するサンプルコードについて 以下はPSR-7/15/17を意識したサンプルコードや疑似コード多め 他のHTTPメッセージの実装でもほぼ同様の考え⽅は可能 Nextat Inc. 17
18. 改めて、Webアプリケーション Nextat Inc. 18
19. 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
20. なるほどいまいちわからん Nextat Inc. 20
21. 馴染み深い例 HTTPリクエストハンドラ ≒ コントローラのアクション class GreetingController { public function hello(ServerRequestInterface $request) : ResponseInterface { $name = $request->getAttribute('name', 'world'); return new JsonResponse(['message' => "Hello, {$name}!"]); } } Nextat Inc. 21
22. 実際はもう少し簡略化されているケースが多い // ルータでパスパラメータが定義される $router->get('/hello/{name}', [GreetingController::class, 'hello']); class GreetingController { public function hello(string $name): array { return ['message' => "Hello, {$name}!"]; } } (HTTPリクエスト →) ルートパラメータ → 配列 (→ JSONレスポンス) 暗黙的な変換でリクエストハンドラ相当の処理が導出されている Nextat Inc. 22
23. 必須の部品1: Router １つのリクエストハンドラ内で複数の機能の処理に分岐すると複雑 パスやHTTPメソッドを基準に機能ごとにリクエストハンドラを分けたい $router->get('/hello/{name}', HelloHandler::class); $router->get('/ping', PingHandler::class); Router = HTTPのレイヤに特化した switch⽂ Router = HTTPのレイヤに特化した match式 （PHP8枠） Nextat Inc. 23
24. 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
25. 必須の部品2: HTTP Middleware リクエストハンドラで同じ処理を何回も書きたくない 共通化するためのMiddleware Nextat Inc. 25
26. コードで⾒ると class MyMiddleware implements MiddlewareInterface { public function process( SeverRequestInterface $request, RequestHandlerInterface $handler ): ResponseInterface { // 前処理 // ... // ハンドラがリクエストを処理 $response = $handler->handle($request); // 後処理 // ... return $response; } } Nextat Inc. 26
27. Middleware = リクエストハンドラ限定の インターセプター リクエストハンドラの処理の前後に割り込んで共通処理を挟み込む リクエストハンドラに対しAOP(Aspect Oriented Programming)を実現 発表後追記： koriyamさんより Middlewareはデザインパターンで⾔えば Chain of Responsiblitiy ですねとのツッコミをいただいてます Nextat Inc. 27
28. ⼊出⼒に注⽬ Request Handler + Middleware = Request Handler Nextat Inc. 28
29. 合成が容易 リクエストハンドラにミドルウェアを複数被せたら再びリクエストハンドラに Request Handler + Middleware * N = Request Handler Nextat Inc. 29
30. Webアプリケーションフレームワークの共通機能 ルートごとのコントローラのアクションをまとめてWebアプリケーションを作る つまり HTTPリクエストハンドラ・ミドルウェアを合成して、 １つの⼤きなHTTPリクエストハンドラを作る と⾔える Nextat Inc. 30
31. リクエストハンドラの中⾝の設計 本資料では個別のリクエストハンドラの中⾝にはあまり触れません 中⾝は好きに作ってくださいというスタンス この部分の設計もやりがいがあるが、Web FWの共通機能ではない フルスタックフレームワーク リクエストハンドラを扱う機能（先ほどまでの説明） 頻出機能を作るための再利⽤可能なコンポーネント群 CLIフレームワーク etc. ※ 本資料で注⽬する ドメイン はHTTP層です Nextat Inc. 31
32. Webアプリケーションの設計を学ぶ → PHP WEBアプリケーション設計⼊⾨――10年先を⾒据えて作る https://speakerdeck.com/nrslib/introduction-to-web-application-design Nextat Inc. 32
33. 3. PHP8新機能の活⽤ Nextat Inc. 33
34. 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
35. After class PostController { public function __construct(PostService $service) {} public function show(int $postId): JsonResponse { $post = $this->service->find($postId); // 略 } } Nextat Inc. 35
36. ⼩クラス主義の後押し コンストラクタから依存するオブジェクトを注⼊するコードが短くなる ⼩さな部品を組み合わせてより複雑な機能を作る 継承より移譲 ⼩クラスが流⾏るのでは？ 例）コントローラ単位のクラス→アクション/リクエストハンドラ単位に Controllersディレクトリ → Handlersディレクトリ Nextat Inc. 36
37. ⼩クラス主義の難点 AがBに依存していて、BがCに依存していて、CがDに依存していて…… ⼈の⼿で⽣成コードを利⽤するすべての箇所で書くのは⼤変 $handler = new GreetingHandler( new GreetingService( new RdbGreetingRepository( new DatabaseConnection( new Pdo($dsn) ) ) ) ); Nextat Inc. 37
38. DIコンテナ ⽣成⽅法を登録しておけば、依存関係を解決したオブジェクトを作ってくれる インターフェースに依存している部分は登録を変更するだけで差し替えられる DIコンテナは⼩クラス主義の強い味⽅ // ⽣成⽅法の登録 $container->bind(GreetingRepositoryInterface::class) ->to(RdbGreetingRepository::class); // （略） // オブジェクトの利⽤側は⽣成⽅法を気にしない $handler = $container->get(GreetingHandler::class); Nextat Inc. 38
39. DIコンテナについて詳しく学ぶ → CakePHPで学ぶDIコンテナ https://speakerdeck.com/itosho525/learn-a-di-container-through-cakephp 説明するととても⻑くなるので助かります！ Nextat Inc. 39
40. 3-2. Attributes クラスやメソッド、プロパティ、引数などにメタ情報を付加する機能 PHP8より前はコメント内の記述で代⽤していた 正式に採⽤されたことで⼤⼿を振って使える いわゆるデコレータとは違うので注意 あくまで⽬印をつけるだけ Nextat Inc. 40
41. 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
42. AOP (Aspect Oriented Programming)に有⽤ Attributesのメタ情報を⼿掛かりにして対応した処理を挟み込む Middlewareを使わずとも横断的な処理を挟むことができるようになる HTTPに関係ない横断処理に有⽤ 参考：Ray.Aop https://github.com/ray-di/Ray.Aop Nextat Inc. 42
43. 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
44. AOPについて詳しく（？）学ぶ → PHP WEBアプリケーション設計⼊⾨――10年先を⾒据えて作る https://speakerdeck.com/nrslib/introduction-to-web-application-design "横断的関⼼毎" という項⽬があったのでおそらく触れられると思います → 発表後追記： 残念ながらMiddlewareの話でした Nextat Inc. 44
45. 3-3. Union Typesなど型に関する機能 Union Types Static return type （PHP7.4ですが） Typed Properties 静的解析ブーム IDEの静的解析の強化 PHPStan, Psalmなど静的解析ツールの進化 静的解析フレンドリーなFWも増えるはず Nextat Inc. 45
46. 静的解析について詳しく学ぶ → レガシープロジェクトで、メタプログラミングを使った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
47. ここまでのまとめ Webアプリケーションフレームワークの備える共通機能や概念を説明 PHPのWebアプリケーションを考えるための下地が整った なんとなくこう共通化すると便利 → より洗練された抽象化へ PHP8の機能の活⽤も夢が広がる Nextat Inc. 47
48. 4. WebアプリケーションFWを取り巻く変化と課題 注）以下独断と偏⾒成分が増えます Nextat Inc. 48
49. フレームワークの制約・個性 共通の機能以外の機能や制約が個性やアピールポイントになる REST・ハイパーメディア ⾼速開発 設定より規約 使い⼼地の揃ったコンポーネント群 etc... 現状の課題からも新しい制約や個性が⽣まれるはず PHPとWebアプリケーションを取り巻く変化を⾒ていこう Nextat Inc. 49
50. 4-1. 様々なデプロイ先とランタイム PHP-FPM以外の選択肢 Swoole https://www.swoole.co.uk/ RoadRunner https://roadrunner.dev/ ReactPHP https://reactphp.org/ Nextat Inc. 50
51. 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
52. 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
53. デプロイ先や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
54. 4-2. Webフロントエンドや他サービスとの連携 PHPのサーバ側アプリケーション１つだけでは完結しない傾向 WebフロントエンドのSPA SaaS、mBaaSの活⽤ チームや機能に合わせたマイクロサービス化 Nextat Inc. 54
55. Webフロントエンドとの連携を例に考える Q. 最⾼の設計のバックエンドと最⾼の設計のWebフロント エンドを組み合わせれば、全体として最⾼のシステムになる だろうか？ A. そうとは限らない Nextat Inc. 55
56. 局所最適化、統合コスト バックエンドとフロントエンドで整合性が取れない 別々に作って繋げようとして初めてうまく繋がらないことがわかる ボイラープレートが増え、作業量が増える 本質的ではないミスも出やすい Nextat Inc. 56
57. システムのつなぎ⽬を上⼿く作る重要性 システム間のインターフェース インターフェースがあれば、⼀旦中⾝の詳細を忘れて⼀段階抽象化した思考がで きる ⼈間が⽊の葉を⾒ながら森も⾒るのは⼤変 APIファースト Nextat Inc. 57
58. 「定義のないAPIなんて  ツメが折れたLANケーブルみたいなもんでしょ」 Nextat Inc. 58
59. アプローチ１： 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
60. アプローチ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
61. コードファーストな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
62. 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
63. 「バックエンドの⾔語でフロントを書ければ良いのでは？」 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
64. システム間をスムーズに繋ぐためのアプローチもいろ いろあって⾯⽩い Nextat Inc. 64
65. 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
66. gRPCについて詳しく（？）学ぶ → PHP8はISUCONへの扉を開く鍵となるか https://docs.google.com/presentation/d/1BgaSPWa5NJTAIC__8kRRx3lzxxim KNvTcxuNWnA0Td0/edit ▪ お話しないこと - パフォーマンス以外の話 - PHP のgRPC 利⽤について ← アッ → 発表後追記： 触れられてませんでした Nextat Inc. 66
67. 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
68. メッセージ駆動、マイクロサービスについて詳しく学ぶ → 事業のスケールアウトを⽀えるPHPで作る分散アーキテクチャ https://speakerdeck.com/ytake/shi-ye-falsesukeruautowozhi-eru-phpdezuo- rufen-san-akitekutiya → Service communication re:Born Nextat Inc. 68
69. 5. 独⾃フレームワーク⾃作のすすめ Nextat Inc. 69
70. ⾃作のすゝめ 開発⼿法の変化や課題があってチャレンジしがいがある 今使っているWeb FWへの理解を深められる ⾃作・⾞輪の再発明は最⾼の勉強⽅法 最初から壮⼤なものを作るのは⼤変 ⼩さく始める 完全に0から作る必要はない 既存のコンポーネントを組み合わせる 薄いFWに後付けで好みの改造を施し開発プロジェクトの効率を上げる Nextat Inc. 70
71. 今は有名なあのフレームワークも 開発当初はオレオレ独⾃フレームワークだった Nextat Inc. 71
72. 誰かのオレオレフレームワークが PHPの世界を変えていく Nextat Inc. 72
73. まとめ PHPのWeb FWの設計を考えるための下地となる概念が整った PHP8の新機能もFWの実装を後押しする Webアプリ開発の課題を解決する新しいFWに期待 例1. 様々なターゲットへのデプロイを楽にしてくれるFW 例2. システム同⼠の繋ぎ⽬をケアしてくれるFW ⼩さな部品を組み合わせてサービス全体を作り上げていく。APIは⼤事 独⾃フレームワーク製作を始めるなら今でしょ！ Nextat Inc. 73
74. PR: We're hiring! 株式会社 Nextat 受託開発 業務システム、ECサイト、ソシャゲ 京都・東京メインで求⼈しています 私も⽉1くらいで東京に通ってます 設計の話に付き合ってくれる⽅⼤歓迎！ Nextat Inc. 74
75. ご清聴ありがとうございました Nextat Inc. 75
76. 本資料の参考にさせていただいたフレームワーク および参考にした点のメモ Nextat Inc. 76
77. 参考フレームワーク（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
78. 参考フレームワーク（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
79. 参考フレームワーク（他⾔語） 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
80. 参考フレームワーク（他⾔語） 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