GraphQL で N+1 問題を解決する 4 つのアプローチ
この記事では TypeScript + Apollo Server + TypeORM を前提として話を進めます。 GraphQL のサーバ実装では 1:N 構造において N+1 問題が発生しがち 技術選定がこれからの場合や、ORM が置き換えられる場合は N+1 を考慮した ORM を検討するのが良い それ以外の場合は DataLoader を実装するのが良さそう。ライブラリを使えばそんなに大変ではない JOIN での解決も可能だが、 GraphQL の道を踏み外している(ように感じる) GraphQL における N+1 問題 GraphQL サーバで 1:N のデータ構造を実装しクエリすると、すぐに N+1 問題に行き当たります。User と Post が 1:N の関係となる、以下の例を見てみましょう。 type User { id: Int! name: String! posts
Next.js x Relay な GraphQL 環境で Render-as-you-fetch の良さを最大限生かしつつ SSR にも対応したいあなたへ - Qiita
Next.js x Relay な GraphQL 環境で Render-as-you-fetch の良さを最大限生かしつつ SSR にも対応したいあなたへRelayGraphQLNext.js はじめに 最近 Next.js ベースのプロジェクトに GraphQL クライアントとして Relay を導入したのですが、これが端的に言ってめちゃくちゃ大変だったので記事にしました。 チームの試行錯誤の結果を余すところなく伝えたいと張り切りすぎた結果死ぬほど長くなってしまったので、「いいからコードはよ」という方は 最終的にこんな実装になりました (コード編）をご覧ください。 謝辞 愛するチームメンバーのみんな。これまでの道のりで私を支え、愛してくれたみんながいなければ、この記事は完成できなかったと思う。 また、この記事が世に出せたのは、スーパーテクニカルアドバイザーである koichik さんの
NestJS x GraphQL x Prismaでさくっとページネーションを実装する
NestJS x GraphQL x Prismaでページネーションを実装しようとしたところ、まだデファクトっぽい方法がなさそうで色々苦労したので対応内容をまとめてみました。 はじめに すでにnestjs/graphql x Prismaの環境が整っているうえで「細かいことはいいからページネーションをさくっと実装したい」という方向けの記事になっています。 そのため、記事中に記載するコードは必要最小限に留めています。 環境 @nestjs/graphql: 10.0.8 @prisma/client: 3.11.1 @devoxa/prisma-relay-cursor-connection: 2.2.2 実装方針 こちらの考えを参考にさせていただきながら、 こちらのライブラリを利用して実装しています。 実装内容（抜粋） 1. 利用するライブラリをインストール 2. @nestjs/grap
GraphQL Code Generator(graphql-codegen) おすすめ設定 for TypeScript
GraphQL Code Generator v3 以降で標準となった Client preset では設定が大きく異なります。 この記事は Client preset を使わない前提の内容になっているため、注意が必要です。 Client preset 用の設定は別記事で紹介します。 全体 生成物をフォーマッタにかける graphql-codegen には Lifecycle Hooks という仕組みがあり、いくつかの用意された hook ポイントで任意のコマンドを実行できる。 これを使って生成されたコードを Prettier 等のフォーマッタに通しておくのがおすすめ。 基本 DO NOT EDIT とはいえ、コードジャンプしてきて生成された型を読みたいケースはよくある。 そういうときのために、人間が見やすいように改行しておいてもらうといい。 typescript plugin, type
メルカリ Shops での NestJS を使った GraphQL Server の実装 | メルカリエンジニアリング
ソウゾウの Software Engineer をやっています、@mookjp です。 8/10 の記事「メルカリShopsの技術スタックと、その選定理由」では、メルカリ Shops のアーキテクチャについて、その全体像を紹介しました。 この記事では、そのうちの BFF（Backend for Frontend） レイヤとして用意した GraphQL サーバについて、NestJS を使った実装例を交えて紹介します。 GraphQL とは GraphQL サーバ周辺の構成 NestJS とは GraphQL Module NestJS で Code First なスキーマ定義をする Object types の定義 Query と Mutation の定義 GraphQL スキーマの生成 スキーマの Breaking Change （破壊的変更）を防ぐ DataLoader を使って Bat
GraphQL スターターパック | Prisma + NestJS + Next.JS製 個人ブログサイトをCloud Runで運用しよう
GraphQL スターターパック | Prisma + NestJS + Next.JS製 個人ブログサイトをCloud Runで運用しよう 「GraphQLの仕様はなんとなく知っているけど、それを使ってどうアプリを作るのかいまいちイメージがわかない」 この本はそんなスキマを埋めるべく書きました。 近年ではReactをはじめフロントエンドの選択肢が豊富になっており、フロントエンドとバックエンド間のやりとりにはより汎用的かつ効率的な方法が求められます。 GraphQLはその選択肢のひとつです。本書では NestJS で GraphQLバックエンドを実装し、それをNext.jsから利用して、個人ブログサイトを構築してみます。 GraphQL開発の流れを体験し、ご自身のアプリ開発に役立ててください。 v1.10 refactor github deploy
GraphQL と Prisma から考える次のN年を見据えた技術選定 / Architecture decision for the next N years at StudySapuri
JSConf JP 2021 で登壇した資料です #jsconfjp #jsconfjp_b Links: [Active Recordから考える次の10年を見据えた技術選定](https://speakerdeck.com/yasaichi/architecture-decision-for-the-next-10-years-at-pixta) [GraphQL を活用したスキーマ駆動開発の実践](https://speakerdeck.com/qsona/schema-driven-development-with-graphql) [GraphQL を利用したアーキテクチャの勘所 / Architecture practices with GraphQL - Speaker Deck](https://speakerdeck.com/qsona/architecture-pract
Relayに学ぶGraphQLのスキーマ設計 - cockscomblog?
2018年の初めくらいから、仕事でGraphQL APIを何度も作っている。サーバーサイドもクライアントサイドも実装している。 最近クライアント側にRelayを使ってみている。 GraphQLのクライアントとしてはApolloを使う場合が多いと思うが、Facebook製のRelayもかなりよくできている。以前はTypeScriptに対応していなかったが、今はTypeScriptも使える。最近のバージョンではhooksのAPIがexperimentalではなくなり、ReactのSuspense API（Suspense for Data Fetchingは使わずに）と合わせて使える。 RelayはGraphQLのスキーマに制約を設けることで、クライアント側のAPIがデータの再取得やページネーションなどを抽象化している。換言すると、Relayからデータの再取得やページネーションに必要なスキーマ
GraphQLとPersisted Query - Qiita
最近、GraphQL APIをインターネット上に晒す上で何を考慮したらいいのだろうか、的なことを考える機会が多く、空いた時間でチマチマと素振りしています。 今日はGraphQLのクライアント - サーバー間に挟むリバプロ的な機能について書いてみようと思います。 やりたいこと 1. 想定しないクエリの排除 例えばECやメディアサイトのような、未ログインでも情報の閲覧が可能なサービスのWeb API層をGrahpQLで実装したとします。ECにしろメディアにしろ、詳細ページでの回遊率を上げるため、詳細同士を関連付けるようなスキーマ設計となるのは自然なことでしょう。 GrahpQLのスキーマ定義で書くと、下記のようなイメージです。 type Product { id: ID! name: String! relatedProducts: [Product] } type Query { produ
React 時代に選ぶ GraphQL - とろろこんぶろぐ
概要 先日新規の Web サービス開発でフロントエンド側の技術選定を行いました。 利用する技術の中で GraphQL を提案した際に、RESTful な API で呼び出す方法と比較して納得感がないという意見があがりました。 そこで、なぜ、どういうときに GraphQL を選定すべきだと思うか、文章にして自分なりにまとめておこうと思います。 前提 構成が BFF か BE かで意見は大きく変わりません。 例えば BFF として利用されるケースでは、バックエンド側には BE チームとマイクロサービス的な API が存在しており、 BFF として GraphQL を配置するようなケースです。GraphQL のリゾルバは API を叩きます。 一方、 BE として利用されるケースとは、リゾルバが直接 DB を叩くような形です。 今回はフロントエンドのチームが管理する BFF として、JS のみで
あなたのプロダクトに Apollo Client は必要ないかもしれない - 一休.com Developers Blog
Apollo Client は複雑 Apollo Client が向いているケース 一休.com に Apollo Client は必要ないかもしれない では何を使えばいいの？ 複雑なアプリケーションには Apollo を使えばいい？ もう一つのリッチなクライアント、Relay の話 結局、何を使えばいいのか この記事は一休 × 出前館 Frontend Meetup でお話した内容をブログにまとめたものです。 user-first.ikyu.co.jp speakerdeck.com GraphQL クライアントと聞いて一番に思い浮かぶライブラリは何でしょうか？ 多くの方にとっては Apollo Client ではないかと思います。npm trends を見ても Apollo Client のダウンロード数は urql や relay などほかのクライアントと比べ圧倒的です。 実際、一休
relay-compilerでinline fragmentのある型定義を生成するときのコツ - 私が歌川です
relay-compiler 13.2.0で確認した。つい昨日にRelay 14が出ていたので試してみたけど同様の結果になった。 特定のinterfaceに対するinline fragment内に、interfaceが共通して持つフィールドも都度列挙して書くと、直和型の __typename フィールドによる型の絞り込みが効くようになる。逆に、共通して持つフィールドをinline fragmentの外に書くと、型の絞り込みが効かなくなる。 # OK: __typenameによる絞り込みが効く fragment Foo_bar_ok on Bar { ... on Bar1 { __typename barField bar1Field } ... on Bar2 { __typename barField bar2Field } } # NG: __typenameで型を絞り込めず、bar
mswとgraphql codegenでGraphQLをモックし、効果的で効率的なReactのテストを書く
はじめに：テスト戦略の話 そもそもフロントエンドのテストって何をどんな粒度で書けばいいの？という疑問はよくあると思います。これについては以前Qiitaの記事: フロントエンドでTDDを実践する（理論編）で書いているので詳細は省きますが、Testing Trophyの戦略に則り、integration testを中心とし、unitテストは本当に有効なものに絞って書くというのがフロントエンドにおいては有効です。 APIモック フロントエンドのintegration testにおいて課題になるのがAPIのモックです。urqlやapollo clientのようなGraphql Clientでもqueryをモックする仕組みはありますが、どちらもclient自体をモックするような書き方になります。一見問題ないようですが、client側でキャッシュの挙動を制御したりできることもあり、本番コードと異なるコ
Getting Started With Apollo Client in Next.js | Apollo GraphQL Blog
March 9, 2021Getting Started With Apollo Client in Next.js (Update May 2023) We published a library that makes it easier to use Apollo Client with Next.js 13, this guide still remains valid if you’re using the pages directory. Wait, you want me to put my data where!? Figuring out how to configure Apollo Client with Next.js can be a bit confusing. This confusion stems from the fact that there are t
Apollo Client と SSR の罠 その1 - パフォーマンス改善編 | Wantedly Engineer Blog
Wantedly でバックエンドエンジニアをしている @izumin5210 です。 この記事は GraphQL Advent Calendar 2020 の11日目の記事として書かれました。が、7割くらいは SSR についての議論のこり3割くらいが Apollo Client の話です。 最近、Apollo Client と SSR(Server Side Rendering) を利用した Web アプリケーションのパフォーマンス改善に取り組みました。この記事では「パフォーマンスの問題にどう立ち向かったか」および「そもそも問題を起こさない構造にするために何ができるか・何をすべきでないか」の考察をしていきます。 TL;DRパフォーマンス改善は計測・可視化からライブラリが用意してくれているフック機構を上手に使って計測していこうrenderToStringWithData では、renderT
ブラウザで動くサービスを作るときの技術選定
はじめに 私の仕事は、新規サービスをまるっといい感じに開発するのを委託されることがほとんどです。最近はネイティブアプリを作ることよりもブラウザで動くWebサービスを開発することが多いのですが、案件の規模感や要求によって技術選定を少し変えるようにしています。「こういうときはこう」みたいに一概には言えないのですが、普段使う構成を紹介します。誰かの参考になれば幸いです。 2022/02/10 現在での内容です。 前提 開発を委託される場合の運用費をどうするの問題があります。クライアントにクレカ登録をしてもらうか、こちらで支払って毎月請求するかになります。僕は毎月やるのがめんどくさいのでできるだけ前者に倒している関係上、あまりいろいろなSaaSを組み合わせて作ることをなるべく避けています。 規模感によらず使っているもの 私の場合、以下が使えるとめちゃくちゃ効率よく開発できます。 GCP 好きだから
Next.js + ApolloでSSRするときにパフォーマンスが低下する問題について
Next.js + Apollo Next.js の公式リポジトリには Apollo を使用する際のサンプルコードがあるが、 これらを参考に SSR するとかなりパフォーマンスが悪い。 with-apollo with-typescript-graphql 例えば、with-typescript-graphql の/pages/index.tsx を見てみる。 ... import { useViewerQuery, useUpdateNameMutation, ViewerDocument, } from '../lib/viewer.graphql' import { initializeApollo } from '../lib/apollo' const Index = () => { const { viewer } = useViewerQuery().data! ... re
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Using GraphQL DataLoaders with NestJS
How to use DataLoader with NestJS - LogRocket Blog
TypeScript による GraphQL バックエンド開発
