Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

n1215
PRO
December 12, 2020

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

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

n1215
PRO

December 12, 2020
Tweet

More Decks by n1215

Other Decks in Technology

Transcript

  1. for PHP Conference Japan 2020
    PHP8時代の
    Webアプリケーションフレームワークの話をしよう
    2020年12⽉12⽇(⼟) 株式会社Nextat 中榮健⼆
    Nextat Inc. 1

    View Slide

  2. ⾃⼰紹介
    京都から配信しています
    - 中榮健⼆ (なかえけんじ)
    - twitter: @n_1215 
    - 株式会社Nextat 取締役
    - Laravel/Unityでソーシャルゲーム開発
    - → ここ最近はECサイト開発多め。Lambda + AppSync なども
    Nextat Inc. 2

    View Slide

  3. 発表概要
    1. はじめに
    2. WebアプリケーションFWの仕組み
    3. PHP8の新機能の活⽤
    4. WebアプリケーションFWを取り巻く変化と課題
    5. 参考にさせていただいたFW
    6. 独⾃FW⾃作のすすめ
    Nextat Inc. 3

    View Slide

  4. 1. はじめに
    Nextat Inc. 4

    View Slide

  5. 当資料の"Webアプリケーション"の範囲
    1リクエストに対して1レスポンスを同期で返すHTTPアプリケーション
    サーバからのストリーミングや双⽅向通信はスコープ外
    WebSocket、GraphQL Subscriptions、gRPC Streaming
    触れたかったが25分では無理
    本スライド中の⽤語の解説について
    時間がないので⽤語の解説をふわっと⾶ばします
    ⼀部は他の素晴らしい発表に含まれているので該当の発表を列挙
    Nextat Inc. 5

    View Slide

  6. 2. Webアプリケーションフレームワークの仕組み
    Nextat Inc. 6

    View Slide

  7. Webアプリケーション
    Nextat Inc. 7

    View Slide

  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

    View Slide

  9. ブラウザのデベロッパーツールから観察
    最近のブラウザは簡単にHTTPメッセージの中⾝が⾒られるので便利
    ↓はChromeのデベロッパーツールのNetworkタブの様⼦
    Nextat Inc. 9

    View Slide

  10. PHPでのHTTPメッセージの処理
    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

    View Slide

  11. HTTPメッセージという単位で扱いたい
    $_GET

    $_POST
    を直接扱うのは細かすぎる
    HTTPという安定したプロトコルを抽象化の基礎にしたい
    プログラミング⾔語⾮依存の概念
    HTTPリクエストとHTTPレスポンスのクラスを作って抽象化
    Nextat Inc. 11

    View Slide

  12. Nextat Inc. 12

    View Slide

  13. HTTPメッセージの実装
    HTTPメッセージの実装がFW・プロジェクトごとに乱⽴していた
    最近は2⼤勢⼒が⽬⽴つ
    PSR-7 HTTP Messages
    Symfony Http Foundation
    Nextat Inc. 13

    View Slide

  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

    View Slide

  15. PSRについて詳しく学ぶ
    → PSRで学ぶHTTP Webアプリケーションの実践
    いつもはPSRの説明やコードをもう少し⼊れるのですが今回は安⼼して省けます!
    ありがとうございます!
    Nextat Inc. 15

    View Slide

  16. Symfony HTTP Foundation
    ⼀番勢⼒の強い[要出典] HTTPメッセージ実装
    Symfonyのコンポーネント
    Laravelでも利⽤される(illuminate/http)
    PSR-7より設計的には少し緩いが、取り扱いは便利
    PSR-7互換のためのブリッジもある
    https://symfony.com/doc/current/components/psr7.html
    Nextat Inc. 16

    View Slide

  17. 注) HTTPメッセージに関連するサンプルコードについて
    以下はPSR-7/15/17を意識したサンプルコードや疑似コード多め
    他のHTTPメッセージの実装でもほぼ同様の考え⽅は可能
    Nextat Inc. 17

    View Slide

  18. 改めて、Webアプリケーション
    Nextat Inc. 18

    View Slide

  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

    View Slide

  20. なるほどいまいちわからん
    Nextat Inc. 20

    View Slide

  21. 馴染み深い例
    HTTPリクエストハンドラ ≒ コントローラのアクション
    class GreetingController
    {
    public function hello(ServerRequestInterface $request) : ResponseInterface
    {
    $name = $request->getAttribute('name', 'world');
    return new JsonResponse(['message' => "Hello, {$name}!"]);
    }
    }
    Nextat Inc. 21

    View Slide

  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

    View Slide

  23. 必須の部品1: Router
    1つのリクエストハンドラ内で複数の機能の処理に分岐すると複雑
    パスやHTTPメソッドを基準に機能ごとにリクエストハンドラを分けたい
    $router->get('/hello/{name}', HelloHandler::class);
    $router->get('/ping', PingHandler::class);
    Router = HTTPのレイヤに特化した switch⽂
    Router = HTTPのレイヤに特化した match式 (PHP8枠)
    Nextat Inc. 23

    View Slide

  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

    View Slide

  25. 必須の部品2: HTTP Middleware
    リクエストハンドラで同じ処理を何回も書きたくない
    共通化するためのMiddleware
    Nextat Inc. 25

    View Slide

  26. コードで⾒ると
    class MyMiddleware implements MiddlewareInterface {
    public function process(
    SeverRequestInterface $request,
    RequestHandlerInterface $handler
    ): ResponseInterface {
    //
    前処理
    // ...
    //
    ハンドラがリクエストを処理
    $response = $handler->handle($request);
    //
    後処理
    // ...
    return $response;
    }
    }
    Nextat Inc. 26

    View Slide

  27. Middleware = リクエストハンドラ限定の インターセプター
    リクエストハンドラの処理の前後に割り込んで共通処理を挟み込む
    リクエストハンドラに対しAOP(Aspect Oriented Programming)を実現
    発表後追記: koriyamさんより Middlewareはデザインパターンで⾔えば Chain
    of Responsiblitiy ですねとのツッコミをいただいてます
    Nextat Inc. 27

    View Slide

  28. ⼊出⼒に注⽬
    Request Handler + Middleware = Request Handler
    Nextat Inc. 28

    View Slide

  29. 合成が容易
    リクエストハンドラにミドルウェアを複数被せたら再びリクエストハンドラに
    Request Handler + Middleware * N = Request Handler
    Nextat Inc. 29

    View Slide

  30. Webアプリケーションフレームワークの共通機能
    ルートごとのコントローラのアクションをまとめてWebアプリケーションを作る
    つまり
    HTTPリクエストハンドラ・ミドルウェアを合成して、
    1つの⼤きなHTTPリクエストハンドラを作る
    と⾔える
    Nextat Inc. 30

    View Slide

  31. リクエストハンドラの中⾝の設計
    本資料では個別のリクエストハンドラの中⾝にはあまり触れません
    中⾝は好きに作ってくださいというスタンス
    この部分の設計もやりがいがあるが、Web FWの共通機能ではない
    フルスタックフレームワーク
    リクエストハンドラを扱う機能(先ほどまでの説明)
    頻出機能を作るための再利⽤可能なコンポーネント群
    CLIフレームワーク
    etc.
    ※ 本資料で注⽬する ドメイン はHTTP層です
    Nextat Inc. 31

    View Slide

  32. Webアプリケーションの設計を学ぶ
    → PHP WEBアプリケーション設計⼊⾨――10年先を⾒据えて作る
    https://speakerdeck.com/nrslib/introduction-to-web-application-design
    Nextat Inc. 32

    View Slide

  33. 3. PHP8新機能の活⽤
    Nextat Inc. 33

    View Slide

  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

    View Slide

  35. After
    class PostController {
    public function __construct(PostService $service) {}
    public function show(int $postId): JsonResponse
    {
    $post = $this->service->find($postId);
    //

    }
    }
    Nextat Inc. 35

    View Slide

  36. ⼩クラス主義の後押し
    コンストラクタから依存するオブジェクトを注⼊するコードが短くなる
    ⼩さな部品を組み合わせてより複雑な機能を作る
    継承より移譲
    ⼩クラスが流⾏るのでは?
    例)コントローラ単位のクラス→アクション/リクエストハンドラ単位に
    Controllersディレクトリ → Handlersディレクトリ
    Nextat Inc. 36

    View Slide

  37. ⼩クラス主義の難点
    AがBに依存していて、BがCに依存していて、CがDに依存していて……
    ⼈の⼿で⽣成コードを利⽤するすべての箇所で書くのは⼤変
    $handler = new GreetingHandler(
    new GreetingService(
    new RdbGreetingRepository(
    new DatabaseConnection(
    new Pdo($dsn)
    )
    )
    )
    );
    Nextat Inc. 37

    View Slide

  38. DIコンテナ
    ⽣成⽅法を登録しておけば、依存関係を解決したオブジェクトを作ってくれる
    インターフェースに依存している部分は登録を変更するだけで差し替えられる
    DIコンテナは⼩クラス主義の強い味⽅
    //
    ⽣成⽅法の登録
    $container->bind(GreetingRepositoryInterface::class)
    ->to(RdbGreetingRepository::class);
    //
    (略)
    //
    オブジェクトの利⽤側は⽣成⽅法を気にしない
    $handler = $container->get(GreetingHandler::class);
    Nextat Inc. 38

    View Slide

  39. DIコンテナについて詳しく学ぶ
    → CakePHPで学ぶDIコンテナ
    https://speakerdeck.com/itosho525/learn-a-di-container-through-cakephp
    説明するととても⻑くなるので助かります!
    Nextat Inc. 39

    View Slide

  40. 3-2. Attributes
    クラスやメソッド、プロパティ、引数などにメタ情報を付加する機能
    PHP8より前はコメント内の記述で代⽤していた
    正式に採⽤されたことで⼤⼿を振って使える
    いわゆるデコレータとは違うので注意
    あくまで⽬印をつけるだけ
    Nextat Inc. 40

    View Slide

  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

    View Slide

  42. AOP (Aspect Oriented Programming)に有⽤
    Attributesのメタ情報を⼿掛かりにして対応した処理を挟み込む
    Middlewareを使わずとも横断的な処理を挟むことができるようになる
    HTTPに関係ない横断処理に有⽤
    参考:Ray.Aop
    https://github.com/ray-di/Ray.Aop
    Nextat Inc. 42

    View Slide

  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

    View Slide

  44. AOPについて詳しく(?)学ぶ
    → PHP WEBアプリケーション設計⼊⾨――10年先を⾒据えて作る
    https://speakerdeck.com/nrslib/introduction-to-web-application-design
    "横断的関⼼毎" という項⽬があったのでおそらく触れられると思います
    → 発表後追記: 残念ながらMiddlewareの話でした
    Nextat Inc. 44

    View Slide

  45. 3-3. Union Typesなど型に関する機能
    Union Types
    Static return type
    (PHP7.4ですが) Typed Properties
    静的解析ブーム
    IDEの静的解析の強化
    PHPStan, Psalmなど静的解析ツールの進化
    静的解析フレンドリーなFWも増えるはず
    Nextat Inc. 45

    View Slide

  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

    View Slide

  47. ここまでのまとめ
    Webアプリケーションフレームワークの備える共通機能や概念を説明
    PHPのWebアプリケーションを考えるための下地が整った
    なんとなくこう共通化すると便利 → より洗練された抽象化へ
    PHP8の機能の活⽤も夢が広がる
    Nextat Inc. 47

    View Slide

  48. 4. WebアプリケーションFWを取り巻く変化と課題
    注)以下独断と偏⾒成分が増えます
    Nextat Inc. 48

    View Slide

  49. フレームワークの制約・個性
    共通の機能以外の機能や制約が個性やアピールポイントになる
    REST・ハイパーメディア
    ⾼速開発
    設定より規約
    使い⼼地の揃ったコンポーネント群
    etc...
    現状の課題からも新しい制約や個性が⽣まれるはず
    PHPとWebアプリケーションを取り巻く変化を⾒ていこう
    Nextat Inc. 49

    View Slide

  50. 4-1. 様々なデプロイ先とランタイム
    PHP-FPM以外の選択肢
    Swoole https://www.swoole.co.uk/
    RoadRunner https://roadrunner.dev/
    ReactPHP https://reactphp.org/
    Nextat Inc. 50

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  54. 4-2. Webフロントエンドや他サービスとの連携
    PHPのサーバ側アプリケーション1つだけでは完結しない傾向
    WebフロントエンドのSPA
    SaaS、mBaaSの活⽤
    チームや機能に合わせたマイクロサービス化
    Nextat Inc. 54

    View Slide

  55. Webフロントエンドとの連携を例に考える
    Q. 最⾼の設計のバックエンドと最⾼の設計のWebフロント
    エンドを組み合わせれば、全体として最⾼のシステムになる
    だろうか?
    A. そうとは限らない
    Nextat Inc. 55

    View Slide

  56. 局所最適化、統合コスト
    バックエンドとフロントエンドで整合性が取れない
    別々に作って繋げようとして初めてうまく繋がらないことがわかる
    ボイラープレートが増え、作業量が増える
    本質的ではないミスも出やすい
    Nextat Inc. 56

    View Slide

  57. システムのつなぎ⽬を上⼿く作る重要性
    システム間のインターフェース
    インターフェースがあれば、⼀旦中⾝の詳細を忘れて⼀段階抽象化した思考がで
    きる
    ⼈間が⽊の葉を⾒ながら森も⾒るのは⼤変
    APIファースト
    Nextat Inc. 57

    View Slide

  58. 「定義のないAPIなんて
     ツメが折れたLANケーブルみたいなもんでしょ」
    Nextat Inc. 58

    View Slide

  59. アプローチ1: 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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  64. システム間をスムーズに繋ぐためのアプローチもいろ
    いろあって⾯⽩い
    Nextat Inc. 64

    View Slide

  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

    View Slide

  66. gRPCについて詳しく(?)学ぶ
    → PHP8はISUCONへの扉を開く鍵となるか
    https://docs.google.com/presentation/d/1BgaSPWa5NJTAIC__8kRRx3lzxxim
    KNvTcxuNWnA0Td0/edit

    お話しないこと
    -
    パフォーマンス以外の話
    - PHP
    のgRPC
    利⽤について ←
    アッ
    → 発表後追記: 触れられてませんでした
    Nextat Inc. 66

    View Slide

  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

    View Slide

  68. メッセージ駆動、マイクロサービスについて詳しく学ぶ
    → 事業のスケールアウトを⽀えるPHPで作る分散アーキテクチャ
    https://speakerdeck.com/ytake/shi-ye-falsesukeruautowozhi-eru-phpdezuo-
    rufen-san-akitekutiya
    → Service communication re:Born
    Nextat Inc. 68

    View Slide

  69. 5. 独⾃フレームワーク⾃作のすすめ
    Nextat Inc. 69

    View Slide

  70. ⾃作のすゝめ
    開発⼿法の変化や課題があってチャレンジしがいがある
    今使っているWeb FWへの理解を深められる
    ⾃作・⾞輪の再発明は最⾼の勉強⽅法
    最初から壮⼤なものを作るのは⼤変
    ⼩さく始める
    完全に0から作る必要はない
    既存のコンポーネントを組み合わせる
    薄いFWに後付けで好みの改造を施し開発プロジェクトの効率を上げる
    Nextat Inc. 70

    View Slide

  71. 今は有名なあのフレームワークも
    開発当初はオレオレ独⾃フレームワークだった
    Nextat Inc. 71

    View Slide

  72. 誰かのオレオレフレームワークが
    PHPの世界を変えていく
    Nextat Inc. 72

    View Slide

  73. まとめ
    PHPのWeb FWの設計を考えるための下地となる概念が整った
    PHP8の新機能もFWの実装を後押しする
    Webアプリ開発の課題を解決する新しいFWに期待
    例1. 様々なターゲットへのデプロイを楽にしてくれるFW
    例2. システム同⼠の繋ぎ⽬をケアしてくれるFW
    ⼩さな部品を組み合わせてサービス全体を作り上げていく。APIは⼤事
    独⾃フレームワーク製作を始めるなら今でしょ!
    Nextat Inc. 73

    View Slide

  74. PR: We're hiring!
    株式会社 Nextat
    受託開発
    業務システム、ECサイト、ソシャゲ
    京都・東京メインで求⼈しています
    私も⽉1くらいで東京に通ってます
    設計の話に付き合ってくれる⽅⼤歓迎!
    Nextat Inc. 74

    View Slide

  75. ご清聴ありがとうございました
    Nextat Inc. 75

    View Slide

  76. 本資料の参考にさせていただいたフレームワーク
    および参考にした点のメモ
    Nextat Inc. 76

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide