TypeScriptだったらFEとBEどっちも書けるし、楽じゃない？ TypeScripter vs PHPerの戦い

PHP Conference Japan 2023
https://fortee.jp/phpcon-2023/proposal/f4740450-4124-4a76-b733-4a0450c011a4

Transcript

1. TypeScriptだったらFEとBEどっちも書ける し、楽じゃない？ TypeScripter vs PHPerの戦い © kaonavi, inc.
2. INDEX 1 .自己紹介 2 .発表の経緯 3 .PHPとTypeScriptとは 4 .型安全性の比較 © kaonavi, inc. 2 5 .ユニットテストの書きやすさ比較 6 .APIを作る上での優位性の比較 7 .まとめ
3. 自己紹介 © kaonavi, inc. 3
4. たまやま りお tamayama rio 自己紹介 © kaonavi, inc. 4 所属 株式会社カオナビ 2020年度新卒入社 職種 バックエンドエンジニア X https://x.com/tama_php
5. 所属 株式会社カオナビ 2020年度新卒入社 職種 フロントエンドエンジニア X https://x.com/nukoneko_tarou 自己紹介 © kaonavi, inc. 5 別府 瞭 beppu ryo
6. 会社紹介 自己紹介 © kaonavi, inc. 6
7. タレントマネジメントシステム「カオナビ」 社員の個性・才能を発掘し 戦略人事を加速させるタレントマネジメントシステム © kaonavi, inc. 7
8. 企画職 Product Manager Product Owner Director エンジニア職 Back-end Engineer Front-end Engineer Native Application Engineer QC Engineer SRE Infrastructure Engineer DevOps Engineer デザイナー職 UI/UX Designer © kaonavi, inc. 8 一緒に働く仲間を募集しています
9. 応募はこちらから https://corp.kaonavi.jp/recruit/list/ © kaonavi, inc. 9
10. 発表の経緯 © kaonavi, inc. 10
11. 皆さんフロントエンドのコード書いてますか？ 発表の経緯 © kaonavi, inc. 11
12. 顧客に価値を素早く届けることを考え、 職種をまたいで開発をするチーム DoDにはテスト完了までと定義されていて、テスト実施もエンジニアがやる UTのテストケースも一緒に考えて負荷を減らす取り組みも実施 発表の経緯 © kaonavi, inc. 12
13. フロントエンドの人がバックエンドやるスイッチングコス ト無い方がよくない？ • FEは破壊メソッドはあまり使わない • JSではこう書くけどPHPだとどうやって書くんだっけ？ • TSだとnumberだけどPHPはint, floatとかたくさんある • constとかつけるけどPHPは変数宣言のキーワードは存在しない？ 
 • 変数のスコープの概念が違うため、置き場所わからん 
 • などなど...
 発表の経緯 © kaonavi, inc. 13
14. 新しい人がチームに来た際に学習コストがかかる 発表の経緯 © kaonavi, inc. 14
15. TypeScriptだったらフロントエンドとバックエンドどっち も書けるし、楽じゃない？ 発表の経緯 © kaonavi, inc. 15
16. PHPとTypeScriptとは © kaonavi, inc. 16
17. C言語で書かれた コミュニティベースで開発されている オープンソースの言語 PHPとは © kaonavi, inc. 17 引用: https://www.php.net/
18. • 1995年 ◦ 開発が開始 • 1995年 6月 ◦ PHPの元祖であるPHP Toolsが誕生 • 1998年 ◦ PHP 3.0 が公開 ◦ ElePHPantのロゴが作られる • 2011年 ◦ Laravel 1の誕生 • 2022年 12月 ◦ 現在では8.2が最新バージョン PHPとは © kaonavi, inc. 18 出典: https://www.jetbrains.com/ja-jp/lp/php-25/
19. メリット • DBとの連携が得意 ◦ 標準であるPDOを使うことで、DBの種類を意識せずとも操作できる • 古くからある言語のため、コミュニティが活発で情報源が豊富 ◦ 日本語での情報が多い上に構文も覚えやすいため、学習コストが低い PHPとは © kaonavi, inc. 19
20. デメリット • 型を意識して記述しないと、コードの肥大化により可読性や保守性が低下する可 能性がある • 自由度が高いゆえに、開発者間で実装の一貫性を保つことが難しい ◦ フレームワークによって補うことは可能 PHPとは © kaonavi, inc. 20
21. Microsoftによって開発された オープンソースの言語 TypeScriptとは © kaonavi, inc. 21 引用: https://www.typescriptlang.org/
22. • 2010年 ◦ 開発が開始 • 2012年 ◦ 最初のTypeScript 0.8が公開 • 2015年 ◦ 安定版であるTypeScript 1.0が公開 • 2016年 ◦ オープンソース化 ▪ GitHubで公開中: https://github.com/microsoft/TypeScript • 2023年 8月 ◦ 現在では5.2が最新バージョン TypeScriptとは © kaonavi, inc. 22
23. TypeScriptとは © kaonavi, inc. 23 メリット • 静的型付け • VSCodeなどのIDEと相性がいい • JSとの互換性 • ライブラリが豊富
24. TypeScriptとは © kaonavi, inc. 24 デメリット • 静的型付けなため制限がかかることもある • 型定義ファイルなどファイル数が少し増える • JavaScriptで書かれているライブラリは@typesパッケージが必要 ◦ 無い場合は.d.tsファイルを自分で作成しなければならない
25. • 型安全性の比較 ◦ TypeScriptで書いたときのメリットって？ • ユニットテストの書きやすさ比較 ◦ テストちゃんと書ける？ • APIを作る上での優位性の比較 ◦ 実際に置き換えられるの？ 発表の経緯 © kaonavi, inc. 25 この２つの言語を下記観点で比較してみて置き換えが 可能か調べてみました
26. 型安全性の比較 © kaonavi, inc. 26
27. PHPとTypeScriptどちらが型安全だとおもいますか？ 型安全性の比較 © kaonavi, inc. 27
28. 型安全性の比較 © kaonavi, inc. 28 ※ただし、JSの拡張なのでanyなどで動的型付けも可能(非推奨) TSは静的型付けなため、 JavaScriptへのトランスコンパイル時にエラーを出す
29. PHPは大部分の型エラーは実行時に TypeErrorとして出力されます 型安全性の比較 © kaonavi, inc. 29 ※PHP7以降では、リテラルの二項演算での型エラーに限ってコンパイル時にエ ラーとなります
30. そもそも、標準のPHPでは暗黙に型変換され るため、型の宣言がほぼ機能しない無法地 帯に・・・ 型安全性の比較 © kaonavi, inc. 30
31. そんな中、PHP7以降では型宣言に対して厳 密に判断するstrictモードがあります 型安全性の比較 © kaonavi, inc. 31 出典: https://www.php.net/manual/ja/migration70.new-features.php declare(strict_types=1);
32. また、静的解析ツールであるPHPStanを導入 することで、暗黙の型変換をある程度制御し、 より厳密な型のチェックができます 型安全性の比較 © kaonavi, inc. 32 
 
※配列などPHPで書けない型も大部分はカバーできる
33. TypeScript VS PHPStan 型安全性の比較 © kaonavi, inc. 33
34. 比較パターン • 数字に文字列を入れようとするパターン • 配列に対する型定義 • 型定義に無い値を取得しようとしたパターン • 型ガード 型安全性の比較 © kaonavi, inc. 34
35. TypeScript 型安全性の比較 © kaonavi, inc. 35
36. 型安全性の比較 © kaonavi, inc. 36 function sum(a: number, b: number) { // Type 'string' is not assignable to type 'number'. a = '3'; return a + b; } console.log(sum(1, 2)); 数字に文字列を入れようとするパターン
37. 型安全性の比較 © kaonavi, inc. 37 配列に対する型定義 interface Hoge { fuga: string; } const hoge: Hoge[] = [ { // Type 'number' is not assignable to type 'string'. fuga: 1 } ]; // Type 'number' is not assignable to type 'string'. const piyo : string[] = [1];
38. 型安全性の比較 © kaonavi, inc. 38 interface Hoge { fuga: string; } const hoge: Hoge = { fuga: 'hello!' }; // Property 'piyo’ does not exist on type 'Hoge'. console.log(hoge.piyo); 型定義に無い値を取得しようとした場合
39. 型安全性の比較 © kaonavi, inc. 39 function hoge(x: number | string) { if (typeof x === 'string') { // OK x.substring(1); } else { // Property 'substring' does not exist on type 'number'. x.substring(1) } // Property 'substring' does not exist on type 'string | number'. x.substring(1); } 型ガードができる
40. PHPStan 型安全性の比較 © kaonavi, inc. 40
41. 型安全性の比較 © kaonavi, inc. 41 function sum(int $a, int $b) { $a = '3'; return $a + $b; } var_dump(sum(1, 2)); // int(5) 数字に文字列を入れようとするパターン
42. function sum(int $a, int $b) { return $a + $b; } // $a of function sum expects int, string given. var_dump(sum('1', 2)); 型安全性の比較 © kaonavi, inc. 42 数字に文字列を入れようとするパターン
43. 型安全性の比較 © kaonavi, inc. 43 class A { // $hoge (array{fuga: string}) does not accept default value of type array{fuga: 123}. /** @var array{fuga: string} */ private array $hoge = ['fuga' => 123]; } 配列に対する型定義 array-shapes: https://psalm.dev/docs/annotating_code/type_syntax/array_types/#object-like-arrays
44. 型安全性の比較 © kaonavi, inc. 44 class A { /** @var array{fuga: string} */ private array $hoge = ['fuga' => 'hello!']; public function get(): string { // Offset 'piyo' does not exist on array{fuga: string}. return $this->hoge['piyo']; } } 型定義に無い値を取得しようとした場合
45. 型安全性の比較 © kaonavi, inc. 45 function format(?CarbonImmutable $date) { if ($date instanceof CarbonImmutable) { // OK var_dump($date->format('Y/m/d')); } else { // Cannot call method format() on null. var_dump($date->format('Y/m/d')); } // Cannot call method format() on Carbon\CarbonImmutable|null. var_dump($date->format('Y/m/d')); } 型ガードができる
46. 完璧とまでは言えないが、PHPStanを導入すればあ る程度の型安全はPHPでも保証できそう 型安全性の比較 © kaonavi, inc. 46
47. ユニットテストの書きやすさ比較 © kaonavi, inc. 47
48. PHPUnit • xUnitの設計を元にしたPHP用のユニットテス トを行うためのフレームワーク • PHPのユニットテストを記述するのに恐らく最 も良く知られている • 自動テストが簡単に書けるので、TDDとの相 性が良い ユニットテストの書きやすさ比較 © kaonavi, inc. 48 引用: https://phpunit.de/
49. Mockが簡単にできる ユニットテストの書きやすさ比較 © kaonavi, inc. 49 class Hoge { public function getHello(): string { return ''; } }
50. Mockが簡単にできる ユニットテストの書きやすさ比較 © kaonavi, inc. 50 class HogeTest extends TestCase { public function test(): void { $mock = $this->createMock(Hoge::class); $mock->expects($this->once())->method('getHello')->willReturn('Hello!'); var_dump($mock->getHello()); // string(6) "Hello!" } }
51. ユニットテストの書きやすさ比較 © kaonavi, inc. 51 xUnitの設計が元になっているので、余計な部 分を考えずに自動化テストが書ける！ • テストするための準備や後処理の場所提供 • 結果と期待値が合致しているかの確認方法 • テストメソッドの判別方法 • etc…
52. jest • meta社製のシンプルさを重視した、快適な JavaScript テスティングフレームワーク ◦ ts-jestと@types/jestが必要 • 別々のプロセスで実行することも可能 • コードカバレッジも対応 • mockもできる ユニットテストの書きやすさ比較 © kaonavi, inc. 52 引用: https://jestjs.io/ja/
53. Expectが豊富 • .toBe(value) • .toHaveBeenCalled() • .toHaveBeenCalledTimes(number) • .toHaveReturned() • .toBeFalsy() • .toBeNull() • .toBeTruthy() • .toBeUndefined() • .toBeNaN() • などなど… ユニットテストの書きやすさ比較 © kaonavi, inc. 53 出典: https://jestjs.io/ja/docs/expect
54. Mockも使える • jest.spyOn() ◦ 特定のメソッドをモックに置き換える • jest.fn() ◦ mock関数として存在しない関数を作り出せる • jest.mock() ◦ モジュール全体をmock化できる ◦ そのファイルに書かれているすべての関数を制御下における ユニットテストの書きやすさ比較 © kaonavi, inc. 54 const spy = jest.spyOn(a, 'get').mockImplementation(() => 'Hello!'); 出典: https://jestjs.io/ja/docs/mock-function-api
55. 機能的にはほぼ互角？ どちらも業務範囲ではやりたいことはできる。 ユニットテストの書きやすさ比較 © kaonavi, inc. 55
56. APIを作る上での優位性の比較 © kaonavi, inc. 56
57. TypeScriptで開発でBEを開発できる 代表的なフレームワーク APIを作る上での優位性の比較 © kaonavi, inc. 57 • Next.js • Nuxt.js • NestJS • SolidJS • …
58. 今回はNestJSを選択 APIを作る上での優位性の比較 © kaonavi, inc. 58 選んだ理由 • サーバーサイドに特化している • DIパターンをサポートしている • Testabilityな設計 特徴 • TSで作られていて、TSで開発しやすい • Angular風 • モジュール式アーキテクチャ • 依存関係の注入ができる • アイコンが猫 +100 引用: https://nestjs.com/
59. PHPの代表的なフレームワーク APIを作る上での優位性の比較 © kaonavi, inc. 59 • Laravel • CakePHP • Symfony • CodeIgniter • …etc
60. 今回はLaravelを選択 APIを作る上での優位性の比較 © kaonavi, inc. 60 選んだ理由 • ドキュメントなど情報が豊富にある • サービスコンテナ、マイグレーションなど 強力な機能が備わっている • EloquentによってDB操作を直感的にできる 特徴 • 最も利用されているPHPフレームワーク • 文法が直感的でわかりやすい • ORMが採用されている 引用: https://laravel.com/
61. LaravelとNestJSでの比較 APIを作る上での優位性の比較 © kaonavi, inc. 61 VS 引用: https://nestjs.com/ 引用: https://laravel.com/
62. 比較パターン • DI • オブジェクトリレーショナルマッピング 型安全性の比較 © kaonavi, inc. 62
63. Laravel 型安全性の比較 © kaonavi, inc. 63
64. APIを作る上での優位性の比較 © kaonavi, inc. 64 DI サービスコンテナによってクラスの依存関係を直感的に解決できる class A { public function __construct(private B $b) { var_dump($this->b->hello()); } } ※ PHP 8.x
65. APIを作る上での優位性の比較 © kaonavi, inc. 65 function getHogeMember(): Member { // membersテーブルから`name`が'hoge'のレコードを取得 return Member::where('name', 'hoge')->get(); } オブジェクトリレーショナルマッピング Eloquentを使用することでDBとのやり取りを直感的にできる また、ActiveRecordパターンを採用しているので、テーブルとモデルクラスが一対一に対応して おり構造が理解しやすい
66. APIを作る上での優位性の比較 © kaonavi, inc. 66 モデルクラスの作成も容易 use Illuminate\Database\Eloquent\Model; class Member extends Model { // }
67. NestJS 型安全性の比較 © kaonavi, inc. 67
68. APIを作る上での優位性の比較 © kaonavi, inc. 68 @Injectable() export class CatsService { private dogService; constructor(dogService: DogService) { this.dogService = dogService; } getCats(): { cats: string[] } { return { cats: [ 'スコティッシュフォールド ', 'マンチカン', 'アメリカンショートヘア ', 'ベンガル', this.dogService.getDogs(), ], }; } } DI Laravelの様なDIもかける しかし、Laravelみたいに自動注入はできず Moduleというものに使うサービスを設定しなけれ ばならない @Module({ controllers: [CatsController], providers: [CatsService, DogService], exports: [CatsService], }) export class CatsModule {} 出典: https://docs.nestjs.com/fundamentals/custom-providers
69. APIを作る上での優位性の比較 © kaonavi, inc. 69 オブジェクトリレーショナル マッピング @nestjs/typeormという公式パッケージがある Entityを作ることによって、MigrateやDB操作を簡 単に行うことができます OneToMany, ManyToOneなどもあるため様々な リレーションもできます import { Entity, Column, PrimaryGeneratedColumn } from 'typeorm'; @Entity() export class User { @PrimaryGeneratedColumn() id: number; @Column() firstName: string; @Column() lastName: string; @Column({ default: true }) isActive: boolean; } 出典: https://docs.nestjs.com/techniques/database
70. APIを作る上での優位性の比較 © kaonavi, inc. 70 Eloquentに近い書き方ができるし、生クエリも書くことはできる where, orderBy, groupBy, limit, offset, joins, leftJoinAndSelect, innerJoinAndSelect, Insert, Update, Delete… const user = await getRepository(User) .createQueryBuilder("user") .where("user.id = :id", { id: 1 }) .getOne(); 出典: https://docs.nestjs.com/techniques/database
71. NestJSでも同じことはできるが、Laravelほど日本の コミュニティが活発ではないため、課題解決に難儀しそ う APIを作る上での優位性の比較 © kaonavi, inc. 71
72. まとめ © kaonavi, inc. 72
73. 最初は夢のような話だったが調べていると TSでFE/BEどちらも書くのは実現性ありそう まとめ © kaonavi, inc. 73
74. ただし、実際のサービスとして使うとどうなの か？などがまだ不明瞭 まとめ © kaonavi, inc. 74 根幹はNode.jsなのでシングルスレッドだったりする
75. 新規開発では試して見る価値はあるが、 学習コストや実装コストを考えると既存システムを置き 換えるほどのメリットはなさそう まとめ © kaonavi, inc. 75
76. ご清聴ありがとうございました！