<h3 id="h8d027c8ed3">はじめに</h3> webシステムでデータの相互通信形式はREST APIやgRPCの他にGraphQLによる形式がある。 厳密にはGraphQLの通信形式はAPIとしての機構だが、クエリによってフロントエンド側が柔軟にデータを取得できる。 僕はREST API形式もGraphQL形式も扱ってきているが、GraphQLの優れている点として <ul><li> 各ページにおいてデータをまとめて取得することで、RESTのように何度も通信する必要がない(ケーニヒスベルクの橋の問題)</li></ul> <ul><li> ApolloやurqlなどのGraphQLクライアントとTypeScriptの型定義の組み合わせで強力なスキーマ駆動開発が可能</li></ul> などが挙げられる。 自分も開発していて数多くの利点を感じている。 一方で僕の中ではGraphQL側が要求する技術的要件の難易度は高いとも思っている。 その理由を次に挙げる。 <h3 id="h797932f52e">N+1問題と解決について</h3> GraphQLとRDBMSは残念ながら相性の良い技術の組み合わせとは言えない。 データの捉え方に両者には隔たりがあるからだ。 GraphQLは木構造を辿りながら、データを捉えることで、データ取得の解決方法を提示している。 一方でデータベース(ここではRDBMSとする)ではテーブルを関連づけてデータを取得する解決方法を提示している。 この木構造を辿るという行為は、例えばユーザー一覧の中で投稿一覧を探索する際にそれぞれのリソースをユーザーのデータ分だけ探索してしまうことに繋がる。 これはデータ数が多くなればRDBMSの発行するSQLクエリの数が多くなってしまい、パフォーマンス面で非常に厄介な問題を引き起こす。 RDBMSに詳しいエンジニアの場合、これをテーブル結合で解決しようとするがGraphQLの「必要なデータのみクライアントが指定する」という考え方に背くことになる。 これは <a href="https://zenn.dev/alea12/articles/15d73282c3aacc" target="_blank" rel="noopener noreferrer">先達者の記事</a> にもある通りである。 最もリーズナブルな解決方法としては記事にあるとおり、ORM層に自己解決させるというやり方だろう。(ID群を取得し、それをWHERE IN句でまとめて取得するやり方) <h3 id="he5c4d0ae2a">木構造と関係性データベース構造の難しさ</h3> GraphQLとRDBMSではデータに対する捉え方が異なる。 この両者が一同に接する接合点でデータをどの粒度で捉えるか、は問題になる。 テーブルの粒度 = GraphQLのスキーマ単位 という考え方は厳密には適用できない、と個人的には考えている。 というより無理に押し込もうとすればするほど上手くいかない。 今のところ共通解は持ち合わせていないが僕の中ではまずGraphQLとして大きなグラフ構造を考えて粒度を決める、その次に必要なテーブルを作成する、というのが良いような気がする。 <h3 id="h29ed6d54e6">プロジェクトでGraphQLとREST APIどちらを使うべきか</h3> まずプロジェクトが新規プロジェクトでデータ取得がある程度複雑になるプロジェクトであればGraphQLを採用するメリットはある。逆にいうとそれ以外のケースではお勧めしない。 例えば <ul><li> 既存プロジェクトのリライトやリファクタリング</li></ul> <ul><li> RDBMSの設計が初期段階で歪な構造になっている</li></ul> こういう状況でGraphQLを採用すれば余計に問題を複雑にするだけである。 実体より手段を先行させないことが大事だと考える。

webシステムでデータの相互通信形式はREST APIやgRPCの他にGraphQLによる形式がある。

GraphQLとRDBMSの考察

<h4 id="h308ceff509">本の紹介</h4> タイトル買いというべきか、とにかくタイトルが興味をそそる内容だったので電子書籍で買った。 <a href="https://www.amazon.co.jp/悲劇的なデザイン-あなたのデザインが誰かを傷つけたかもしれないと考えたことはありますか？-ジョナサン・シャリアート-ebook/dp/B078LX5GQV" target="_blank" rel="noopener noreferrer">悲劇的なデザイン-あなたのデザインが誰かを傷つけたかもしれないと考えたことはありますか？</a> この本は世の中に存在する「悲劇的なデザイン」を紹介し、なぜひどいのか、至った要因などを事例ごとに紹介する。 事例はユーザーに怒りを感じさせるデザイン、悲しみを感じさせるデザイン、疎外感を感じさせるデザインである。 一番しっくりきた言葉は「地獄は善意でできた道である」というワードである。アメリカのことわざらしい。 自分が良かれと思ったデザインはユーザーに不信感を抱かせたり、怒りを感じさせる側面があることを常に忘れてはいけない。 もちろん全員が満足するようなデザインなんて作るのはかなり難しい話である。(今のところそんなデザインは誰も発明してない) ただ「かなり多くの」人間が信頼し、満足できるデザインというのは目指せるかもしれない。 そのためにアクセシビリティというのは結局あるのだから。 あんまり話すとネタバレになるので、詳しくは書籍を買って読んでほしい。ページ数は300ページぐらい。

タイトル買いというべきか、とにかくタイトルが興味をそそる内容だったので電子書籍で買った。

ジョナサン・シャリアートのデザイン書籍を読んだ

<h4 id="h1a2bc1336c">個人的な振り返り</h4> 今年も色んなことがあった。 面白いこともあれば、それほど面白くないこともあったけど次に続く道筋はできたと思う。 僕が仕事で費やした時間を見ると、以下に要約される。 1. プロダクトのフロントエンド実装(4割) 2. テストコード作成(3割) 3. タスク管理や割り振り(2割) 4. OSSの更新や調査(1割) 特に2のテストコードは力を入れた。 <a href="https://zenn.dev/k_n/articles/f55d8ad6a843d1" target="_blank" rel="noopener noreferrer">Zennで投稿した記事</a>にある通り、カバレッジ率を0%から最低限の70%まで持ってこれたので結構がんばった方ではないかと思う。 「テストを書く、が当たり前」がもっと世の中に浸透してくれればと思うし、自分自身も積極的に発信できればと考える。 なぜなら再現性のないもの(ここでは画面も見ないとわからない)を確認しないといけない実装は実装ではない、という自負がある。 一方で一つ後悔したことといえば、「アクセシビリティ」の観点で足りない部分が色々あったなぁというところである。 具体的には文字やボタンの色のコントラクト比でもうちょっと深い議論ができれば、とか、エラーの見せ方とか。 来年の課題は「アクセシビリティ」の知識をさらに増やし、実践していくこと。 いっぱい本も読むこと。 あと趣味でやってるRustもう少し勉強したいなぁ。。。 <h4 id="h9224cd51c5">周辺界隈振り返り</h4> 今年も数えきれないほど技術の変化があったけど、やはり一番はNext.js 12である。 Next.js 12については<a href="https://nextjs.org/blog/next-12" target="_blank" rel="noopener noreferrer">ここ</a>にあるので読んでほしい。 その中でもEdge Function は一番わくわくする。 リクエストがオリジンに到達する前に関数を実行し、ベーシック認証とかリダイレクトとかを実装できるので、便利そう。(ぶっちゃけ Lambda Edgeでも同じことできるじゃん?とか言わない) 他にはReact 18(React Server Component)を意識したアップデートの内容になっている。 自分はまだReact Server Componentの概念が曖昧なのでもうちょっと勉強してみる予定。 あとはゲームチェンジャーとも言える<a href="https://deno.land" target="_blank" rel="noopener noreferrer">Deno</a>である。 今後どのぐらいNode.jsからDenoへの技術的置き換えが起きるのかわからないけど、このコミュニティの動きは見守りたい。

2021年を振り返る。今年も色んなことがあった。面白いこともあれば、それほど面白くないこともあったけど次に続く道筋はできたと思う。

2021年を振り返る

フロントエンドのテストは見るべき部分が多く、大変だと言われている。 複雑性の本質を見るとフロントエンドのプログラミングがロジックに合わせて画面UIが変化をする、に起因すると考える。 フロントエンドで行うテストの種類は <ol><li>ロジックレベルの単体テスト</li><li>UIコンポーネントテスト</li><li>結合テスト(E2Eテスト)</li><li>リグレッションテスト</li></ol> が挙げられる。(他にもあるかもだが) <h4 id="h44a6d4560e">ロジックレベルの単体テスト</h4> 最も取り組みやすいものの一つ。 関数単位でそれぞれのパターンごとに期待値を書いていき、判定を行う。 エンジニアがいう「テストコード」でいうと真っ先に思い浮かぶやつ。 ReactやNextでは以下のライブラリが非常に良い。 <a href="https://testing-library.com/docs/react-testing-library/intro/" target="_blank" rel="noopener noreferrer">https://testing-library.com/docs/react-testing-library</a> 気をつけている点としては 質の悪いテストコードを書かない →結果が自明である関数のテストコードはわざわざ書かない 闇雲に書くとメンテナンスコストは高くなるし、やる範囲は絞った方が良い。 自分の場合の優先順位だと下記に絞っている。 1.ドメインロジック層 2.カスタムフック層 3.通信層の一部 <h4 id="h900897c258">UI単体コンポーネントテスト</h4> これも比較的取り組みやすいものの一つ。 先程のテストライブラリや状況によってはStorybookも代用になる。 スナップショットによるコンポーネントテストは一時期やっていたが、DOM要素が複雑になると確認がしづらくなり、途中でやめた。 <h4 id="h240642deb2">結合テスト(E2Eテスト)</h4> 非常にやりづらいテスト。 最近はCypressとかが出てきて随分楽になった。 ただし、こちらは自動テストツールだと起動や実行が遅い場合があり、特にテストファイル数が多くなると顕著になる。 結合テストについてはサービスで特に重要な機能だけに自動化を絞ってCypressに回させた方が良い。 人間の介入が引き続き必要とする領域と思われる。 <h4 id="ha631e69f04">リグレッションテスト</h4> いわゆる退行テスト。 修正したコードが他の無関係な部分に影響が及んでいないかを確認するテスト。 UIのリグレッションテストについてはreg-suitとstorycapである程度自動で行うことが可能となっている。 導入自体は難しくはないが、こちらもやる範囲を決めないと無駄なケースが増えると思われる。 <a href="https://github.com/reg-viz/reg-suit" target="_blank" rel="noopener noreferrer">https://github.com/reg-viz/reg-suit</a> <a href="https://github.com/reg-viz/storycap" target="_blank" rel="noopener noreferrer">https://github.com/reg-viz/storycap</a> フロントエンドのテストは本当にやり出すとキリがない状態になる。 なので現状においては必要なタイミングで必要なツールを用いて、範囲と目的を限定させて実行するのが良さそう。

フロントエンドのテストは見るべき部分が多く、大変だと言われている。
複雑性の本質を見るとフロントエンドのプログラミングがロジックに合わせて画面UIが変化をする、に起因すると考える。



フロントエンドのテストの複雑性

ブログ記事を自分の学習のために見直す時があるのだが、記事数が10件超えると検索が欲しくなる。 なので作ってみた。 まだ未対応な機能としてページネーションとOR検索があるけど、まぁそれはそのうち必要になったら実装すれば良いやぐらいな感覚で。。 SSGだとクライアントから直接検索のAPIを叩くわけにはいかないので、そこらへんは文献を読んで、クライアントからは APIを直接叩かない方法で実装した。このあたりの実装方法も面白いので今度紹介できたらと思う。 あとは個人的にはnext/routerの使い方とか勉強になったりしたのでとても良い体験になった。 余談だがNext.jsやNuxt.jsでプロダクトを実装するとフロントエンドのフルスタック化が凄まじいと感じる。 多分将来的にフロントエンドエンジニアという肩書きはなくなりそう。 アプリエンジニアとか、もっと領域が広くなるとフルスタックエンジニアになるかも。

ブログ記事を自分の学習のために見直す時があるのだが、記事数が10件超えると検索が欲しくなる。
なので作ってみた。まだ未対応な機能としてページネーションとOR検索があるけど、まぁそれはそのうち必要になったら実装すれば良いやぐらいな感覚で。。

My Blog

GraphQLとRDBMSの考察

ジョナサン・シャリアートのデザイン書籍を読んだ

2021年を振り返る

フロントエンドのテストの複雑性

ブログ記事に全文検索を追加した