Rails+Next.jsでGraphQLを導入する時に考えたこと - Timee Product Team Blog
こんにちは、タイミー開発プラットフォームチームで業務委託として働いている宮城です。 タイミーはリリースから4年が経過したプロダクトで、2022年の前半から一部領域でGraphQLを利用し始め現在導入を進めています。 本記事では、GraphQLをプロダクトに導入する上で判断に迷った箇所や課題に対して、タイミーでの意思決定とその理由を紹介します。参考にしていただければ幸いです。 GraphQLの選定理由についてはこの記事では触れませんが、CTOの@kameike が以下のイベントで詳しく紹介する予定です。まだ参加申し込みは可能ですので、興味がある方はぜひ合わせてご覧ください。 timeedev.connpass.com なお、本記事のタイトルはソウゾウさんの以下の記事にインスパイアされています。 engineering.mercari.com GraphQLの「Getting Startedの
GraphQL の Fragment Colocation について
TL;DR 考え方 コンポーネントとセットで、そのコンポーネントが必要なデータを Fragment で宣言する、React の宣言的 UI に合わせた宣言的データ取得（declarative data-fetching）という考え方 Component Scopedに取得データを宣言することで「そのコンポーネントで必要なデータはなにか」を管理しやすくなることで、under-fetching / over-fetching が抑制でき、変更にも強くなる お悩みポイント Fragment-scoped な変数を定義するための標準機構がない Relay は directive を利用した独自の機構を持つ 便利そうなライブラリ graphql-anywhere クエリ結果を Fragment の形に整形する not actively support apollo-link-fragment-arg
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
