モダンWebフロント個人的ピックアップ #1

2 min read読了の目安(約2200字

GraphQLが解決する問題とその先のユースケース

https://zenn.dev/saboyutaka/articles/07f1351a6b0049
  • その後生まれて来ているユースケース
  • GraphQL導入の検討

要約

GraphQLが解決した問題

  • API インターフェース: APIインターフェースとしてGraphQLを導入することによってフロントとバックエンドが柔軟に実装・変更が可能。
  • クライアントリソースの軽減: 状態管理をGraphQLクライアントが自動化してくれるため、クラサバ間のキャッシュ・状態管理にReduxを使う必要がなくなった(クライアント側で発生する状態管理にはReduxを使うケースはある)

利用の中で生まれて来たユースケース

  • マルチクライアント: 異種クライアントやユーザー毎のUIを作りやすい。
  • API層のAnti-Corruption(腐敗対策) Layer: APIインターフェースとしてGraphQLを導入することによってインクリメンタルな変更・改善が可能。
  • Realtime API with Subscription: Subscriptionで状態をサーバープッシュで受け取ることが可能。
  • 巨人の肩に乗る: 新しい技術は既存技術の課題解決をしている可能性が高いので、新しい技術を率先して使う。

GraphQLの導入するタイミング

  • GraphQLが向いているケース: 変化・進化し続けるアプリケーション。複雑性の高いアプリケーション。
  • クラサバ間での状態同期が必要かどうか
  • 複数種類のクライアントがある
  • Microservicesを採用している
  • 大規模なアーキテクチャ変更が必要

感想

巨人の肩に乗る気持ちでGraphQLを使っていたので非常に勉強になりました。

感想というより疑問点ですが、「GraphQLが解決した」というより、「BFFによって解決できる」の方がしっくりくる...?と思うところがありました。例えば「API インターフェース」などです。
アーキテクチャなどまだまだ詳しくないので詳しい方是非教えていただけるとありがたいです🙏(そもそも僕の解釈が間違っていたらご指摘頂けると嬉しいです)

Next.jsのISRで動的コンテンツをキャッシュするときの戦略

https://zenn.dev/catnose99/articles/8bed46fb271e44

要約

  • getStaticPropsの返り値にrevalidateを指定する。
  • revalidate: 10と設定した場合、10秒間はそのキャッシュを返す。10秒経過後の最初のリクエスト時にキャッシュを更新する。しかし、10秒以降の最初のリクエストに対しては以前のキャッシュを返す。
  • posts/[id]などの動的ルーティングの場合は、getStaticPathsも合わせて指定する必要がある。
  • fallback: 'blocking'を指定するとキャッシュがまだ作られていないときはSSRのようなことを行える。
  • 強整合性が求められるページにISRは向いていない
  • ブラウザにマウントされてから最新のデータを読み込み直すことで、ISRをしながら最新のデータを表示することができる。

Next.jsでApolloクライアントを使い始める

https://www.apollographql.com/blog/getting-started-with-apollo-client-in-next-js/

要約

SSGまたはISR、SSRを使うときはHooksを使わずに直接Apolloクライアントをインポートし、それぞれgetStaticProps, getServerSideProps内でフェッチする。

React Hooksでテストをゴリゴリ書きたい - react-reduxやaxiosが使われているような場合もゴリゴリテストを書きたい

https://zenn.dev/bom_shibuya/articles/5c3ae7745c5e94

最近フロントエンドのTDDに興味を持って挑戦中で、Hooksのテストを書く際に見つけました。なぜTDDに興味を持っているのかというと、設計向上による保守性の向上と、適切なテストによるサービスの信頼性の向上です。今まではテストへの挑戦を拒んできましたが、一定期間何か発見があるまでどんどんテストを書いてみようと思います。

なんとなくでやらないReact.memo戦略

https://zenn.dev/bom_shibuya/articles/b07da034fc5686

要約

  • 基本的にはstateの持ち方やコンポーネントの分割を適切に行うことで再レンダリングを防げる。
  • 現実問題、たくさんのstateを持つコンポーネントが出てくる。
  • その時は
    • useCallbackで不必要に関数が新しく作り直されるのを防ぐ(これをしないと、callback関数はpropsで渡すことになるので、無駄に再レンダリングされることにつながる)
    • memoでpropsが変化していないのに、不必要に再レンダリングされるのを防ぐ。