React Server Components と GraphQL のアナロジー
Next.js の App Router が安定版となり、React Server Components (以下 RSC) を実際に試す環境が整ってきた。 実際、今年はやれどこそこのプロダクトが Next.js を採用しただのやっぱり捨てだのといった話題が尽きなかったように思う。 かくいう自分自身も、今年は App Router の案件に取り組んで RSC と格闘する日々を送っていた。 その過程で、こんなようなことを考えるようになったので、今回はこの辺りの話を書き残しておこうと思う（何回か X に同じ旨の POST は上げていたけど、一回もちゃんとまとめてなかったので）。 RSC がない頃の、別の言い方をすると getServerSideProps を使っていた頃の、Next.js におけるアプリケーションの設計は、トラディショナルな MVC にかなり近しい。 ここでいう MVC は、Sp
GraphQL実践ノウハウ/graphql-knowhow
GraphQL実践ノウハウv2 https://speakerdeck.com/sonatard/graphql-knowhow-v2 宣言的UIの状態管理とアーキテクチャSwiftUIとGraphQLによる実践 https://speakerdeck.com/sonatard/swiftui-graphql GraphQLの誤解 https://speakerdeck.com/sonatard/rethinking-graphql
GraphQLはサーバーサイド実装のベストプラクティスとなるか - Qiita
この記事は GraphQL Advent Calendar 2020 14 日目の記事です。 前回の記事は @joe-re さんの 「ライブラリの実装からCursor-based paginationにおけるcursorのフォーマットのベストプラクティスを探る」 でした。 前置き GraphQLは2010年代後半に出てきた技術の中でも個人的に特に強力なアプリケーション実装パターンの一つだと思っているのですが、シンプルな実装なのに利用用途が豊富にあることと利用する立場が違うと全く印象を抱く事から全体像を掴みづらく、本来持つべきポテンシャルに対してまだ認知が広がっておらず利用されていないように感じます。 今回はサーバーサイドからの視点を中心にGraphQLを構築する要素を分解して解説するのとともに、それを利用した際にWebアプリケーション開発やそれに関わるエンジニアに起きうる変化について書いて
GraphQLにおけるエラーハンドリングの仕方 - ZOZO TECH BLOG
こんにちは、サーバーサイドエンジニアの竹若です。今回GraphQLにおけるエラーハンドリングを調査、Ruby on Railsとgraphql-rubyを使って実装する機会があったので、そこで得られた知見を共有させていただきたいと思います。(なお今回の実装はプロダクション環境には出ていません) GraphQLの仕様とプラクティス それではまず初めに、GraphQLが仕様に定めているレスポンスの返し方を見ていきましょう。 レスポンスのフォーマットに関するプラクティス GraphQLのプラクティスの1つに、レスポンスのhttp statusを200で統一し、レスポンスのerrorsキーにエラーの詳細な情報を持たせるというものがあります。 なぜならGraphQLではリクエストに複数のクエリを含めることができるからです。 https://www.graph.cool/docs/faq/api-ee
GraphQL採用サービスで任意カラムを取得できる脆弱性を見つけた話
初Zennです。 はじめてZennを使ってみました。いつもはTwitterにいるmipsparcです。鉄道と関連技術が好きで、本職ではPHPを書いています。別途ブログもあります https://mipsparc.wordpress.com/ 今年6月、TABICA(7/26に改称し、新名称「aini」、運営会社 株式会社ガイアックス)というイベント募集仲介サービスに、個人情報を自由に取得できる脆弱性を見つけて報告したところ、速やかに修正されて報奨金をいただいた話をします。 GraphQLは知ってますか? はじめに、GraphQLはご存知でしょうか。普通のHTTP API(RESTともいいますが)では、リクエストするエンドポイントが用途ごとに決まっているのが普通でしょう。たとえば /userdata にアクセスすると、JSONなどの形式でユーザーデータの決まった内容が帰ってくるものです。
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
世のフロントエンドエンジニアにApollo Clientを布教したい - Qiita
こんにちは。いかがコーディングお過ごしでしょうか。 私は今更ながら最近GraphQLで遊び出し、そしてApollo Clientに出会いました。 ワクワクしました。「これは想像以上に既存のフロントエンドの設計・実装を変えるものだぞ！」と感じました。 「Apollo ClientってGraphQLクライアントでしょ？GraphQLエンドポイントない俺には関係ないな。」と思ったそこのあなた、それだけじゃないんですApollo Clientは！！！！！ 本記事では「Apollo Clientとはなんぞや」という話と「なぜ私がApollo Clientを布教したいのか」という点について語ります。実は最初は実装含めたチュートリアルを書いていたのですが長くなり過ぎたため記事を二つに分けました。この記事はどちらかと言うと概念系の話が多めで、片方にApollo Client + Reactのチュートリアル
Apollo ClientのInMemoryCacheとMutationに関する調査・考察 - yigarashiのEMブログ
本記事は はてなエンジニアAdvent Calendar 2019 3日目のエントリーです。 はじめに Apollo Client （執筆時 v2.6.4）は、Apollo プラットフォームが提供する JavaScript で実装された GraphQL クライアントです。Apollo Client には InMemoryCache （執筆時 v1.6.3）という強力なキャッシュ機構が用意されており、クエリの結果をキャッシュすることができます。このキャッシュ機構は、多くの場面で API サーバーとの通信回数を削減しパフォーマンスの向上に貢献します。しかし、Mutation によるオブジェクトの作成・更新・削除を行う際には、Apollo Client を使う側がその変更をキャッシュに反映するよう意識する必要があります。例えば、オブジェクトAを含むリストがキャッシュされていたとして、オブジェクト
GraphQLとクライアントサイドの実装指針.md
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
Mutations and Input Types | GraphQL
If you have an API endpoint that alters data, like inserting data into a database or altering data already in a database, you should make this endpoint a Mutation rather than a Query. This is as simple as making the API endpoint part of the top-level Mutation type instead of the top-level Query type. Let’s say we have a “message of the day” server, where anyone can update the message of the day, a
GraphQLのN+1問題を解決する DataLoaderの使い方 - 一休.com Developers Blog
こんにちは。宿泊事業本部の宇都宮です。この記事では、GraphQLサーバ実装時に遭遇するN+1問題と、その解決のために使えるライブラリを紹介します。 フィールド単位でresolverを用意する N+1問題 GoのDataLoaderライブラリ DataLoaderの仕組み DataLoaderのサンプルコード DataLoaderとDataDog APM むすび 採用情報 フィールド単位でresolverを用意する GraphQLでは、クライアントのクエリに応じてオンデマンドに結果を取得できます。 たとえば、以下のクエリを投げると… { accommodation(accommodationId: "00001050") { name } } 以下のようなレスポンスが取得できます。 { "data": { "accommodation": { "name": "マンダリン オリエンタル 東
Queries and Mutations | GraphQL
Queries and Mutations On this page, you’ll learn in detail about how to query a GraphQL server. Fields At its simplest, GraphQL is about asking for specific fields on objects. Let’s start by looking at a very simple query and the result we get when we run it: You can see immediately that the query has exactly the same shape as the result. This is essential to GraphQL, because you always get back w
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GraphQLとの向き合い方2022年版