フロントエンドアプリケーションの開発を行う上で避けては通れないデータフェッチの実装。 REST APIを使うか、GraphQLを使うか、クライアントでキャッシュするか、APIレスポンスにどのようにして型を付けるか、状態管理はどうするのかなど、開発者の悩みが尽きないけれども、それに関しての設計を考えたり議論を行うのはフロントエンド開発の楽しいポイントだと僕は思っています。 この記事では、バックエンドにHasura、フロントエンドにNext.jsを使用する場合に僕が最強だと感じたツールの組み合わせ・使い方を紹介します。 モチベーション APIからのレスポンスにはTypeScriptの型が勝手についてきてほしい。asで型アサーションするのはやりたくない。 クライアントでもサーバー（SSR）でもデータフェッチの方法が同じインターフェースで提供されてほしい。 クライアントでAPIレスポンスをキャッシ
はじめに 現在携わっているプロジェクトの技術選定で GraphQL を使うことになり、 GraphQL クライアントとして Apollo Client を採用することになりました。 最初は GraphQL をクライアントサイドで便利に使えるようにしてくれるものくらいの認識で、クライアント側の状態管理には別途 Redux とか入れるのかなと思っていたのですが、調査の過程でたまたま Apollo Client は Redux を置き換えるとの記事を見かけたので Apollo Client のキャッシュの仕組みと状態管理について少し調べてみました。 この記事では下記のことについて解説します。 Apollo Client とは Apollo Client のキャッシュの仕組み Reactive variables を利用したローカルの状態管理について かなり内容がもりもりになってしまったのですが、
はじめに はじめまして、株式会社スタメンのミツモトです。 普段は、REST API をベースに React + Redux で開発しています。 最近になり開発者体験の向上、プロジェクトのスピードアップという観点から、社内でスキーマファーストな開発に関心が集まっています。そういった背景もあり弊社でも GraphQL の勉強会を始めました。今後のプロジェクトにおいて GraphQL を導入する可能性があるため皆で学んでいます。 React ✕ GraphQL という技術を採用する場合、client 側の状態管理ライブラリとして Apollo Client が挙げられます。 API のレスポンスを正規化かつキャッシュしてくれる Apollo Client の inMemoryCache の恩恵は大きく、開発者だけでなくユーザーにおいても画面の表示速度向上などのメリットがあります。 Apollo
前回は、Apollo GraphQL における Mutation(トランザクション処理)の前提知識としてキャッシュ機構について説明しました。(記事はこちら) 今回は React Apollo(v2) における Mutation 後のキャッシュ更新処理について整理しつつ、どのパターンをどのユースケースで採用すべきかについてまとめてみました。 Mutation 後のキャッシュ更新処理 Mutation の返り値を使う(Optimistic UI/update) Refetch Subscription どう使いわけるか Mutation 後のキャッシュ更新処理 Mutation後のキャッシュ更新処理は大きく分けて3種類あります。それぞれ順番に紹介していきます。 Mutation の返り値を使う(Optimistic UI/update) まず、一番ベーシックな方法として、Mutation の返
2020終わり頃のApollo Client 3から、 reactive variables なるものが追加されたようです。リアクティブな変数を持たせることができるようになったということです。 New in Apollo Client 3, reactive variables are a useful mechanism for storing local state outside of the Apollo Client cache. Because they're separate from the cache, reactive variables can store data of any type and structure, and you can interact with them anywhere in your application without using G
January 29, 2021Redux to Apollo: Data Access Patterns As part of NerdWallet’s migration from our React-Redux code base to client state management using Apollo, we’ve been exploring how to effectively implement data access patterns, side-effects handling, and other aspects of client state management using GraphQL and Apollo Client. This first post examines how we accomplish effective data access, f
こんにちは、エンジニアの川上(@natsumican63)です。 前回は、Webエンジニアのみで、ReactNativeアプリ開発を行った話を書きました。 ReactNativeアプリを開発した際、下記の技術を使用しました。 TypeScript React Native GraphQL Apollo Client 今回は、これらの技術スタックを用いた開発を行ってみた際の模様について、お伝えしていこうと思います。 要約 Rexux/Mobx等の状態管理ライブラリを使用せず、Apollo Clientのキャッシュ機構とReactのlocal stateのみで状態管理を行った @apollo/react-hooksを利用することで、通信周りのコードの見通しが良くなった TypeScript(クライアント側)と、GraphQLの型システムで、更に型安全な開発が望める Apollo Clientの
実際どうなのかという話。正直、今更感ですが、それでもあまりまだそうでもなかったりしてるので。 ※前提として、Apolloを使っているということは、要はGraphQLをバックエンドに持っているという意味である。 Apolloでステート管理は、思ったより現実的な使い方があると思っていて ステート管理は今までならReduxが2015年ぐらいから普通に使われてきたが、それから取って代わるものがあまりなくて、もちろんあるにはあるのだが、結局Reduxが選択されてきたと思う。 で、今年の春ごろにやっとフックがリリースされて、そのおかげで小規模なものにはReduxを入れなくてもそれなりなコードで仕上げることができるようになった。 カスタムフックなどをうまく使えば、それこそReduxなしでちゃんとステート管理できる。 もちろん、使い方を間違えれば、スパゲティコードみたいなものができてしまうが。 それでは、
WE BUILD THE SOFTWARE THAT POWERS BUSINESS. We are your mobile and web developer partners who specialize in rapid prototyping, minimal viable product creation, project rescues, and developer mentorship. LET’S TALK We’ve built extraordinary web and mobile software products for clients for over 10 years. From start-ups to enterprise clients, Haught Codeworks consistently delivers.
はじめに Apollo Client 3における便利なページネーション機能をご紹介します。 concatPagination Apollo Clientのページネーションは、これまでoffsetベースの実装だとfetchMoreを使った以下のような実装になっていましたが、 Before <Feed entries={data.entries || []} onLoadMore={() => fetchMore({ variables: { offset: data.entries.length }, updateQuery: (prev, { fetchMoreResult }) => { if (!fetchMoreResult) return prev; return Object.assign({}, prev, { entries: [...prev.entries, ...fet
graphql-codegen を用いた GraphQL, TypeScript, React-Hooks の連携Tweet 実際のコード https://github.com/superyusuke/react-typescript-apollo-bff-codegen youtube へのリンク https://youtu.be/XJSTqUQQ9GQ GraphQL Codegen を用いて GraphQL のコードから型安全な TypeScript 開発に必要なコードを生成できる Sever 側 Schema に対応した TypeScript の型を生成する Resovler の型を Schema から生成する Server の Context の型を生成する（Apollo Server を立てるときに外から注入した DB や、Apollo Sever への request に含ま
GraphQLとクライアントサイドの実装指針.md GraphQLとクライアントサイドの実装指針 GraphQLって何 Facebookが開発した クエリ言語 今はGraphQL Foundationに移管されている https://quramy.github.io/graph-api-note/#/ GraphQLの特徴 スキーマと静的な型 Demand Driven Architecture Composition 1. スキーマと静的な型 スキーマには可能なクエリや操作の全てが記述されている。 表現方法はいくつかあるが、SDL(Schema Definition Language)で表現されることが多い。 type User { id: ID! name: String! age: Int friends: [User] articles: [Article] } type Arti
最近、空いた時間でチマチマとApolloを触っているのだけど、どうも腑に落ちないことがあったのでメモを残しておきます。 先に言っておきますが、特に何の結論もないです。 GraphQLのFragment colocationとは 僕が直面している課題感を説明するために、クライアントサイドGraphQLにおけるFragment colocationについて整理してみましょう。 "colocate" という単語自体、普段はそうそう耳にしないと思います（僕もGraphQLの文脈以外で使ったことがない）。「一緒に配置する」といった意味のようです。 では、何と何を一緒に配置するのでしょうか。それはGraphQLクエリとコンポーネントです（ここでのコンポーネントは、ReactやAngularにおけるViewの部品単位を指します）。 GraphQLの大きな特徴の1つに「クエリのレスポンスに含まれるデータは
こんにちは。いかがコーディングお過ごしでしょうか。 私は今更ながら最近GraphQLで遊び出し、そしてApollo Clientに出会いました。 ワクワクしました。「これは想像以上に既存のフロントエンドの設計・実装を変えるものだぞ！」と感じました。 「Apollo ClientってGraphQLクライアントでしょ？GraphQLエンドポイントない俺には関係ないな。」と思ったそこのあなた、それだけじゃないんですApollo Clientは！！！！！ 本記事では「Apollo Clientとはなんぞや」という話と「なぜ私がApollo Clientを布教したいのか」という点について語ります。実は最初は実装含めたチュートリアルを書いていたのですが長くなり過ぎたため記事を二つに分けました。この記事はどちらかと言うと概念系の話が多めで、片方にApollo Client + Reactのチュートリアル
vivit株式会社でフロントエンドエンジニアをしている関です。 新型コロナウイルス感染症(COVID-19)への対策として発出された緊急事態宣言の影響で、弊社も2ヶ月ほどリモートワークとなり、私も駆け足で自宅に作業環境を構築しました。買っちゃいましたL字デスク。 さて、弊社ではいくつかのプロダクトのフロントエンドに React(Next.js) + TypeScript を採用しており、バックエンドとの通信には GraphQL(Apollo) を採用しています。 今回はその中で、コンポーネント分割をする際の GraphQL Query の定義と取得したデータの受け渡しについて話をします。 ここからは GitHub GraphQL API v4 を使って説明していきます。 developer.github.com アジェンダ pages から components へのデータの受け渡し方法に
TypeScript 今回のリニューアルで求められたことの一つとして、さらなる改善・新規機能追加などをしていく上で、ソフトウェア品質を担保するための、アプリケーションの堅牢さがありました。 そこで、フロントエンド側の開発言語としては、プログラムコード内で宣言された型によって、エラーを未然に防ぎつつ、VSCode をはじめとするエディタのコード補完の恩恵を受けられるメリット等を考慮して TypeScript の採用を決めました。また、他のプロジェクトでも既に TypeScript は部分的に利用し始めていた事情もあり、逆に TypeScript を採用しない、という選択肢はあまり考えられませんでした。 React UI を構築するためのライブラリ/フレームワークは React を採用しました。こちらも、弊社では別プロジェクトで React を既に利用し始めていたこともあり、学習コストの観点か
graphql-codegen で型定義を生成する (React, Apollo, TypeScript)TypeScriptReactGraphQLapollo 本記事はこのリポジトリでやったことのまとめです。 GraphQL + TypeScript への課題感 TypeScript(に限らず他の静的型付の言語) と GraphQL を使うと、型の二重定義が発生がちです。折角 GraphQL に通信規約としての型を書いているのに、それを多重定義することで、運用の面倒臭さやバグの温床になりかねない、という懸念がありました。 今回は、graphql のスキーマとクエリを書くと、サーバー向けに resolver の型定義、クライアント向けにクエリの型定義を生成し、それによってできるかぎり型安全なコードを扱うのをゴールとします。 やり方 graphql-code-generator を使います
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
