概要 Pages Router から App Router 移行時に一部既存の画面での CSR 遷移が 404 エラーになりました。 この件について調査したので、記事にしてまとめておきます。 前提 今回発生したバグの内容の再現環境の特徴として、以下が挙げられます。 Next v13.5.6 Base path の設定あり App Router と Pages Router が共存している Base Path について Base Path の設定は next.config.js に以下のような記載があると、 module.exports = { basePath: '/base', } /pages/examples.tsx で配置したページコンポーネントが、 URL /base/examples で閲覧できるようになるものです。 また以下のような Link コンポーネントは、自動的に Ne

はじめに 今年の 2023年5月に Next.js の v13.4 がリリースされ App Router が Stable になり Vercel 推奨の実装方式となりました。 さらに10月 Next Conf にて、 Next.js v14 がリリースされ App Router を代表する新機能である Server Actions が Stable になりました。 App Router はこれからのWeb開発の未来を担うフレームワークになっていくことが予想されており注目度の高い技術です。一方、これまでの Pages Router からの変更点の多さ、機能の興味深さ、設計の複雑さ、動作の不安定さなども含め、さまざまな要因でいまでもたくさん議論になっています。 今後どこかのタイミングで App Router へ対応する必要があることは明らかなものの、技術の不安定さが気になる上に、ある程度規模の

記事の概要 この記事は、Meta 社 relay.dev チームの Jordan Eldredge 氏の Tweet で紹介された GraphQL 成熟度モデル (GraphQL maturity model) を個人的な見解を加えながら和訳した記事です。 jordaneldredge.com GraphQL を実装する上で、どの程度 GraphQL を使いこなせているか判断するための参考になれば幸いです。 実際の成熟度モデルの和訳 最初の Tweet 私は、GraphQLの利点がまだ十分には理解されていないと思っています。ほとんどの組織では、GraphQL の提供する価値を捉えきれていません。 そこで、私は「GraphQL成熟度モデル」をスケッチしてみました。あなたの組織はどの程度成熟して（＝使いこなせて）いますか？ もし以下に示す13の成熟度を達成していたとしたら、よりGraphQLを

概要 msw はいつの間にかモックツールとしてデファクトスタンダードになりました。 github.com Mock Service Worker という名の通り、Service Worker を利用して、アプリが API サーバーとやりとりするリクエスト/レスポンスをモックすることができるツールです。 ただ、ふと気がついたら Service Worker なしでモックできるようになっていたので、その小ネタを書きます。 この記事は Recruit Engineers Advent Calendar 2022 の9日目の記事です。 adventar.org Node でも使える msw ご存じの方も多いと思いますが、 msw は Node.js でも利用できます。 Node - Getting Started - Mock Service Worker Docs Node.js で利用できるの

はじめに リリースされたプロダクトをエンハンス開発していく上で、保守性を保ち続けることがとても大事なのは言うまでもありません。 特に複雑な要件は実現するために難解なロジックを書く必要があります。 このことから 要件の複雑さと保守性はトレードオフになりがち です。 保守性を保つ方法はさまざまです。 例えば、可読性を高めるような書き方をした上でコメントを残したり、 Lintやテストなどツールを使ったりなどです。 しかし、この記事では書き方やツールではなく、 そもそも複雑になりそうな仕様を整理し要件から取り外すこと で保守性を保つ取り組みを紹介します。 この記事は Recruit Engineers Advent Calendar 2022 の2日目の記事です。 adventar.org 開発者が仕様の整理に入り込む フロントエンドエンジニアをやっていると、カジュアルに難解なUI要件が定義された

概要 TypeScriptでフロントエンド開発をしているとバックエンドのAPIを呼び出す際に、APIのパラメータ、レスポンスの型付けをしたくなります。 僕は最近この型付けにZodを使い、APIクライアントにはZodiosというライブラリを使っています。 github.com この記事では、Zodios でZodのスキーマ定義から型安全なAPIクライアントを作る方法を紹介します。 他のやり方 Types定義 純粋にパラメータとレスポンスの type を Type Alias で定義し、fetch やaxios などの素のAPIクライアントに型付けするやり方です。 APIのパスと、パラメータ、レスポンスの紐付けを人間が管理することになるため、ミスを防ぐことができません。 aspida この課題のためにaspidaがよく使われている印象があります。 github.com Open APIからas

概要 GraphQL の理解を進める上で参考になったものを載せます。 React.js, TypeScript, Relay が使われるプロダクトを想定しています。 コンセプト GraphQL 公式 GraphQL とは、を正確に知るための公式ドキュメントです。 graphql.org GraphQLとクライアントサイドの実装指針 GraphQL とはどういうものかが読みやすくまとめられています。 GraphQLとクライアントサイドの実装指針.md · GitHub GraphQL との向き合い方 2022 年版 2022 年現在における GraphQL の特徴がスライドでわかりやすくまとめられています。 speakerdeck.com Render as you fetch incremental GraphQL fragments Fragment Colocation のコンセプトが

概要 先日新規の Web サービス開発でフロントエンド側の技術選定を行いました。 利用する技術の中で GraphQL を提案した際に、RESTful な API で呼び出す方法と比較して納得感がないという意見があがりました。 そこで、なぜ、どういうときに GraphQL を選定すべきだと思うか、文章にして自分なりにまとめておこうと思います。 前提 構成が BFF か BE かで意見は大きく変わりません。 例えば BFF として利用されるケースでは、バックエンド側には BE チームとマイクロサービス的な API が存在しており、 BFF として GraphQL を配置するようなケースです。GraphQL のリゾルバは API を叩きます。 一方、 BE として利用されるケースとは、リゾルバが直接 DB を叩くような形です。 今回はフロントエンドのチームが管理する BFF として、JS のみで