GraphQLはどんな時に使うか
@saboyutaka 合同会社春秋 Tech Base Okinawa 2023
@saboyutaka 合同会社春秋 Tech Base Okinawa 2023
GraphQLはいつ使うか、RESTとの比較
さぼです、沖縄でWebと設計について考えてます。2023/09/23 に沖縄で行われたTechBaseOkinawa2023 にて上記のタイトルで登壇しました。 今回の内容は GraphQLを設計の観点から考えてみる GraphQLの目的や用途を整理する GraphQLを使う時、または使わない時のヒントを持ち帰ってもらう 最近、GraphQLじゃなくてRESTで良くないと思うケースがなんとなくわかってきたのでそれを共有する という感じで話しました。話した内容を文字に起こし少し改修してZennでも共有することとします。 まえおき 最近はクライアントAppとサーバーAppを分けて実装する事が増えてきた クライアントの環境はますます複雑になっている クライアントとサーバーはWebAPIで通信を行う クライアントが複雑になるのと同時にWebAPIの要求が更に増して来ている APIの要求・応答を効率
9ヶ月かけて全ての API を REST から GraphQL にリプレースした話 - がぶちゃんの日記
サマリー システム構成の変遷 創業フェーズ はじめての API と技術選定 GraphQL 移行直前 GraphQL への移行を決めたきっかけ GraphQL 移行方針 移行期間 ふりかえり 1つ目の方針は正解だった 2つ目の方針は微妙だったかもしれないけど、正解だったかもしれない 3つ目の方針はやはり苦戦した さいごに サマリー サービス開始から3年経った Next.js + Rails なシステム 全ての API を REST から GraphQL にリプレース 約9ヶ月かかりました 早速フロントエンドの都合でバックエンドにも手を入れるということが減って快適です という話です。 システム構成の変遷 創業フェーズ 1人目エンジニアとして入社して、何から手を付けようかなーと考えた結果、事業の肝の部分からシステム化していくことにしました。弊サービス https://moneiro.jp/ は
GraphQL「良さ」・「難しさ」再探訪 〜スタディサプリにおける実例〜 / StudySapuri with GraphQL
2024/02/08 に「LayerX、スタディサプリ、SHEと考える GraphQLが向いている現場とは？運用実践LT」で、内山高広( @highwide )が発表した資料です。 #Offers_GraphQL実践LT
GraphQL is an incredible piece of technology that has captured a lot of mindshare since I first started slinging it in production in 2018. You won’t have to look far back on this (rather inactive) blog to see I have previously championed this technology. After building many a React SPA on top of a hodge podge of untyped JSON REST APIs, I found GraphQL a breath of fresh air. I was truly a GraphQL h
Backend エンジニア視点からの GraphQL / GraphQL from a perspective of backend engineer
"LayerX、スタディサプリ、SHEと考える GraphQLが向いている現場とは？運用実践LT" で登壇した資料です。 引用した資料 [Rails アプリに RESTful API のレールを敷いて生産性が大きく上がった話 | Wantedly Engineer Blog](https://www.wantedly.com/companies/wantedly/post_articles/85098) [React Server Components と GraphQL のアナロジー | by Yosuke Kurami | Dec, 2023 | Medium](https://quramy.medium.com/89b3f5f41a01) [実質無料で GraphQL Gateway を手に入れる / low-cost GraphQL Gateway - Speaker Deck](
Next.js の App Router が安定版となり、React Server Components (以下 RSC) を実際に試す環境が整ってきた。 実際、今年はやれどこそこのプロダクトが Next.js を採用しただのやっぱり捨てだのといった話題が尽きなかったように思う。 かくいう自分自身も、今年は App Router の案件に取り組んで RSC と格闘する日々を送っていた。 その過程で、こんなようなことを考えるようになったので、今回はこの辺りの話を書き残しておこうと思う（何回か X に同じ旨の POST は上げていたけど、一回もちゃんとまとめてなかったので）。 RSC がない頃の、別の言い方をすると getServerSideProps を使っていた頃の、Next.js におけるアプリケーションの設計は、トラディショナルな MVC にかなり近しい。 ここでいう MVC は、Sp
はじめに こんにちは、retail HUBで Software Engineer をしているほんだです。 今回は私が現在着手している事業譲渡されたアプリを社内で持続的なプロダクト開発を行える状態にするリプレイスプロジェクトをどのように行っているか紹介しようと思います。 この記事ではリプレイスを行うにあたってどのようなことを課題に感じてその課題に対してどのような解決策をとったか主にサーバーの実装について説明しています。 ネットスーパーアプリとは 現在弊社ではネットスーパーアプリとして Web アプリとスマホアプリの二つのシステムを提供しています。 Web アプリは販促コンテンツの設定や売り上げの管理・集計を行うことが可能な管理システムと受け取り方法に応じた価格変更や送料変更にも対応し、消費者の柔軟な買い物を実現するお客様向けアプリを 17 の小売り様に、スマホアプリでは Web アプリのお客
この記事はTSKaigi2024での以下の私の発表内容を書き下ろしたものです。 なぜAPIに型をつけたいのか 現代のWebのシステム開発において、クライアント・サーバーともに型のある言語で開発されることが増えてきました。静的な型検査はコードの堅牢性やよりよいメンテナンス性の向上をもたらします。 プログラミング内部だけで型検査をするだけでも十分メリットはありますが、外部I/Oに対する型付けが不十分だとそのメリットを最大限に発揮してるとは言えません。外部I/Oとは、例えばWebフロントエンドだとLocalStorageやDOMからの入力値、それからネットワーク通信（今回はこれをAPIと呼びます[1]）などですね。サーバー側でいうとAPIからの入力・レスポンスやデータベースへの読み書きが該当します。 個人的な経験から言うと、Webシステムの開発におけるエラーの多くはAPIやデータベースとのやり取
イベント「【タイミー/Voicy/令和トラベル】Backend LT〜技術選定における“見極める力”とは〜」での登壇資料 https://reiwatravel.connpass.com/event/306794/
はじめに マイクロサービスの開発では、サービスが増え続けるバックエンドに対して、フロントエンドは接続先が増えるため、開発効率を下げてしまいます。その対策として、さまざまな設計パターンが存在します。 弊社の開発ではGraphQL Gatewayを用いていますが、そこに至るまでや周辺の技術/アーキテクチャを解説します。 マイクロサービスとフロントエンド マイクロサービスを採用する場合、フロントエンド（ウェブアプリケーション、モバイルアプリケーションなど）は複数のサービスとの連携が必要になることが多いです。各マイクロサービスは通常、API（REST、gRPCなど）を提供し、フロントエンドはこれらのAPIを通じてデータの取得や操作を行います。 API Gateway API Gatewayは、フロントエンドとマイクロサービス間の中間に位置するコンポーネントとして機能し、マイクロサービスアーキテクチ
銀の弾丸ではないので良し悪しあるのは当然として、それを差し引いても以下の2つの要素があるのではと思った。 なんとなく使ってもメリットが十分得られない RESTでできてたことができなくなる（※ちゃんと調べればできる） なんとなく使ってもメリットが十分得られないWeb界隈は良くも悪くも新しい技術をとりあえず使ってみるところがあると思っていて、そこがGraphQLは十分に事前知識を持って導入しないとメリットが薄いところとミスマッチを起こしてネガティブな意見が出るのかなと思う。 GraphQLはもともとFacebookがReact, Relayとの組み合わせで使い始めたもので、クライアントライブラリとしてのRelayと、IDやページネーションについての追加仕様を公開している。ライブラリとしてのRelayは使わなくても仕様に乗っかることはできるのでそれをRelayスタイルと言ったりする。出典を忘れた
「2024年こそ使いこなす！GraphQL最前線」で発表した資料です。 ソニーのホームエンタテインメント領域では、TVやサウンドバー、ヘッドホンをはじめとする様々な製品、それらに付随するアプリケーションを取り扱っています。我々はホームエンタテインメント領域の横断組織として、それらの製品・アプリに対してクラウドサービスを提供しています。この領域において頻繁に要求される機能の一つに、データ配信があります。従来は製品・アプリの案件ごとにそれぞれ個別にサービスを開発しており、サービス間連携やリソースの共通化など横断組織ならではの利点をうまく発揮することができていませんでした。本セッションでは、この問題を解決すべく開発した共通データ配信プラットフォームについて、そこで活用されているGraphQLという技術との関係について、お話しします。
GraphQL実践ノウハウv2
GraphQL実践ノウハウ https://speakerdeck.com/sonatard/graphql-knowhow 宣言的UIの状態管理とアーキテクチャSwiftUIとGraphQLによる実践 https://speakerdeck.com/sonatard/swiftui-graphql GraphQLの誤解 https://speakerdeck.com/sonatard/rethinking-graphql
GraphQL 成熟度モデルの紹介と、プロダクトに当てはめた事例 / GraphQL maturity model
2024/04/19 「tsukiji.graphql」で発表したスライドです。 https://tsukiji-graphql.connpass.com/event/314173/ 参照したURL - https://mh4gf.dev/articles/tags/graphql - GraphQL 成熟度モデル - とろろこんぶろぐ - GraphQL を Server Components で使いたい - Speaker Deck
GraphQLサーバーは、本当にGoがTypeScriptより早いのか。Flutterからの呼び出しで検証する。
3秒まとめ GoのパフォーマンスはNestJS（TypeScript）の2倍以上!? GraphQLのエコシステムはGo, TSともに充実 GitHub Copilotで、GoのAcceptance Rateが40%を超える体験をした GraphQL全盛の時代に、どの言語を使って開発すべきか 2015年にFacebookにより公開されたGraphQL。日本でもYahooやメルカリなどバックエンドをマイクロサービス化している多くの企業で採用され、近年はフロントエンド開発者にとって魔法の弾丸のように扱われることも多くなりました。 メルカリShopがGraphQL Client Architecture Recommendation社外版を公開していることからもわかる通り、GraphQLの利用に関する知見はかなり蓄積されてきています。 上記Recommendationによれば、BackendはG
バックエンド視点で振り返るGraphQLを採用したプロダクト開発 - enechain Tech Blog
はじめに 技術スタック eScanチームにおけるGraphQLの使い方 開発フローの工夫 N+1問題の対応と注意点 エラーハンドリングの工夫 モニタリングの工夫 ドキュメンテーションを必須化するための工夫 その他の取り組み 振り返り 良かった点 難しかった点 今後の展望 最後に はじめに こんにちは、enechainでソフトウェアエンジニアをしている小沢です。 私が所属しているチーム(以降、eScanチーム)では、eScanという電力会社向けのリスクマネジメントシステムを開発・運用しており、その中でGraphQLを採用しています。すでにGraphQLを採用するメリット・デメリットについて様々なところで語られていますが、eScanチームでもオーバーフェッチが解消できる点、1リクエストで必要なデータをフェッチできる点などのメリットを享受するために採用しています。 今回は実際にGraphQLを採
Exploring the Implementation of “t.Run”, “t.Parallel”, and “t.Cleanup”
Signed Query は GraphQL の Trusted Document の新しい実装パターンです - スタディサプリ Product Team Blog
こんにちは。スタディサプリの小中新規開発チームで Web エンジニアをしている @YutaUra です。 去年の４月に新卒で入社をしまして約 1 年が経ちました。インターン生時代にもブログを書いているのでご興味あれば合わせてご覧ください。 GraphQL と Persisted Query スタディサプリ小中講座ではデータ通信に GraphQL を採用しています。 GraphQL を利用することで、クライアントはスキーマに定義された範囲で自由にデータを取得することができます。 query GetUser { user { name age } } また、 GraphQL はデータのグラフ構造に基づいて関連する複数のデータを一度に取得することができます。 query GetUser { user { name age posts { title content } } } GraphQL の
Relay-style GraphQL
🇰🇷 한국인 (Korean) translation available (courtesy of Yujin Lim) “The future Relay-style GraphQL is already here – it’s just not evenly distributed.” – William Gibson, probably ”Relay-style GraphQL” is an opinionated way of consuming GraphQL in a React application, and probably better than whatever you’re currently doing. It follows the ideas pioneered by Meta’s open-source GraphQL library, Relay.
GraphQL is for Backend Engineers | Apollo GraphQL Blog
Most articles explaining the benefits of GraphQL focus on advantages for the frontend: things like preventing overfetching, reducing round trips, and iterating faster. But GraphQL provides just as many advantages for backend developers, which is why I choose it by default for new APIs and why you should consider it, too. Improved communication The goal of building any API is to enable someone to u
GraphQLのスカラーとTypeScriptの考察
皆さんこんにちは。筆者は最近、TypeScriptからGraphQLを使用するためのコード生成ツールnitrogqlを開発しています（初手宣伝）。 直近は、GraphQLのスカラーに関する機能拡張を行っていました。この記事では、そこで得た知見と考察について共有します。 GraphQLのスカラーとは GraphQLにおけるスカラーとは、それ以上分解できないデータ型のことです。GraphQLのデータはスカラー・オブジェクト・enumに分類でき、データの末端はスカラーまたはenumになります。 GraphQL仕様では組み込みのスカラー型が定義されており、以下のものがあります。 Int Float String Boolean ID また、カスタムスカラーとして、追加のスカラー型をスキーマ上で定義することもできます。 スカラー値がサーバー・クライアント間でやり取りされるときはシリアライズする必要が
GraphQLサーバの構成要素を整理する #ハッカー鮨 #tsukijigraphql / graphql server technology selection
tsukiji.graphql x ハッカー鮨 https://tsukiji-graphql.connpass.com/event/314173/
Why, after 8 years, I still like GraphQL sometimes in the right context
A recent post, Why, after 6 years, I’m over GraphQL, made the rounds in the tech circle. The author argues that they would not recommend GraphQL anymore due to concerns like security, performance, and maintainability. In this post, I want to go over some interesting points made, and some points I think don't hold up to scrutiny. Always be Persistin' Ok, first of all, let's start with something may
GraphQLとは何か？ イメージを掴む
はじめに 今回の記事ではGraphQLについて、公式などを参考にしながら基本的なことをまとめてみました。 自分自身GraphQLのキャッチアップを始めるときに こんなこと知っときたかったなあ、ということをまとめたので これからGraphQLの勉強を始める方や興味のある方はよかったら読んでみてください。 大枠を掴むことをイメージして書いており、深い部分の説明を省いている箇所もあるので その点はご了承ください。 そもそもGraphQLとは？ GraphQLはAPIのクエリ言語です。 クエリ言語というとSQLが有名ですが、SQLがデータベースに対してクエリを実行するのに対し、 GraphQLはAPIに対してクエリを実行します。 ちなみに、プログラミングにおけるクエリとは データに対する問い合わせや要求などを一定の形式で文字に表現すること、 要は所定の形式で対象のデータにやりたいことを伝えること、
BARフロントえんどう #1 「フロントエンドリアーキテクト」で使用した資料です！ https://cybozu.connpass.com/event/297123/
はじめに 以前RustとWASMでマークダウンパーサーを自作したので、これを使ってブログを作ってみました。 ソースコードは以下にあります。 技術構成 技術構成は以下のようになっています。 全体構成 フロントエンド Next.js / Type Script Apollo Client(状態管理ライブラリ) styled-components emotion mantine ミドルウェア Prisma BFF GraphQL Yoga(GraphQLサーバー) Pothos GraphQL(GraphQL スキーマビルダー) バックエンド Rust+WebAssembly(マークダウンパーサー) (Vercel Postgress(サーバレスストレージ)) Supabase デプロイ先 Vercel(FE/BF共通ホスティング先) 認証・認可 NextAuth ドメイン取得 Cloudfla
GraphQL のレスポンスのモックデータの作成を補助する TypeScript ライブラリを作った - mizdra's blog
GraphQL を使って Web アプリケーションを実装していると、GraphQL API のリクエストをモックしたいことがあると思います。 ユニットテストのために、ダミーレスポンスに差し替えたい ビジュアルリグレッションテストのために、ダミーレスポンスに差し替えたい Storybook で story を書くために、ダミーレスポンスに差し替えたい バックエンドの resolver 実装を待たずにフロントエンド側の開発を始めるために、ダミーレスポンスに差し替えたい 一般には GraphQL Client にモックするための機能が実装されてるので、そうしたものを使うことが多いと思います。 zenn.dev また最近は Client よりも外側のレイヤーでリクエストを interrupt してモックする「msw」を使うケースも増えてきてます *1。 blog.engineer.adways.n
この記事は LayerX のエンジニアブログがたくさん出る #ベッテク月間 の8記事目になります。こちらのカレンダーに、これまでの記事と今後出る予定がまとまっています。 LayerX のバクラク事業部には GraphQL Gateway というバクラク全プロダクトから参照される GraphQL スキーマが存在します[1]。今回の記事は、その GraphQL Gateway のスキーマをより良い状態にしていくためにぶつかった課題を強引に突破したときの話です。 モチベーション GraphQL スキーマの破壊的変更によって GraphQL Document がスキーマに適合しなくなる場合、そのリクエストはエラーになります。例えば以下のようなケースが考えられます： 使わなくなったフィールドを削除したい 削除されたフィールド（存在しないフィールド）を含む Document を処理することはできない
「攻撃者の視点から見たGraphQLのセキュリティ」というタイトルで登壇したのは、kuzushiki氏。「おもしろかった脆弱性」について解説し合い、脆弱性に関する知識を深めるためのイベント「Security․Tokyo #2」で、「GraphQL」の機能による悪用と、対策について発表しました。 登壇者の自己紹介 kuzushiki氏：それでは、発表を始めていきたいと思います。 まず簡単に自己紹介をさせてください。私は、kuzushikiと申します。現在、とあるセキュリティベンダーで診断員をやっていて、主にWebアプリケーションの脆弱性診断をしています。最近、バグバウンティに興味を持って、そういうものをちょっとやってみています。 “開発者フレンドリー”という特徴を持つ「GraphQL」 今回は「GraphQL」について話しますが、その前に、もうGraphQLを知っているよという方は、どのぐら
Kaggle Tokyo Meetup2023 CommonLit Solutionの紹介と考え方 - Fulltrain戦略と(Seed/Model)Ensembleの可視化 -
GraphQL Schemaの破壊的変更をCIで検知する
ここ数年、私はGraphQL APIサーバーの開発を行っています。GraphQLは柔軟かつ強力なAPIクエリ言語で、Webフロントエンドからモバイルアプリなどいくつかのクライアントがそれぞれ画面に必要なデータをフェッチしており、フロントエンドの開発パフォーマンスが向上しました。 破壊的変更の問題 私のチームではGraphQLサーバーはRailsとGraphQL Rubyを用いてCode First[1]で開発しています。 しかし、複雑性が増すにつれてクライアントやクエリの全体像を把握できずに破壊的変更を引き起こすこともあり、その変更が既存のクライアントに影響を与えないように注意深くSchemaを管理する必要があります。 実際に最近、fieldやmutationの引数の変更がクライアントに不具合をもたらす事態に発生しました。 破壊的変更の検知 そもそもGraphQLは仕様が網羅されているSc
ついにGraphQLに入門した！
今さらですが！GraphQL、ついに、挑戦しました👏 興味はあったものの、まだ着手できていなかったのですが、お仕事の関係もあり、挑戦するに至りました。 ということで！GraphQLとは何なのかから、どう実装したのかまでを整理しておこうと思い、本記事を作成しました！ GraphQLを使ったことなくても、「へー、大体こんな感じなんだなー🤔」みたいな感じで伝われば良いなと思っています。 挑戦したこと 今回挑戦したのは、GraphQLです！ 「GraphQLってどうやって使うの？」っていうことを学ぶところから、実際に自分で使ってみる、サービスを軽く実装してみるっていうところに挑戦しました。 ちなみにこんなの実装してみました。 みんな大好き、タスク管理ですね👏 GraphQLって何？ まず、GraphQL とは何かについて、整理していきます。 概要 A query language for y
GitHub - webpod/graphql-megaera: GraphQL to TypeScript Generator
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
レスポンスヘッダにプロファイラのURLを含めるとGraphQLのパフォーマンスチューニングに便利という話
こんにちは！株式会社アルダグラムのKANNAの開発お手伝いをさせて頂いているoubakiouです。 KANNAではサーバーサイドにRails+GraphQL Ruby、クライアントサイドでApollo Clientを利用していますが、どこの会社であれGraphQLであれRESTであれサービスが成長するとその裏側のパフォーマンスチューニングが必要になる場面が大なり小なり訪れると思います。KANNAもその例に漏れずユーザー数の増加や今までにない規模のお客様企業への導入に伴い、それまでは問題の無かったGraphQLクエリーのいくつかでレスポンス速度に問題が出始めていました。 本番環境においてはDatadogなどで監視環境を構築しスロークエリーやパフォーマンスの監視を行っていますが、開発環境においてはRails部分にrack-mini-profiler、graphql-ruby部分に独自Trace
はじめに 今回はタイトルの通り、「GraphQLは「オワコン」「流行らない」のか？」という問に対して、個人的に調査した内容となります。 今回のタイトルで記事を書くことにしたのは、Googelの検索フォームに「GraphQL」と入力したところ、サジェストに「Graphql 流行らない」「Graphql オワコン」と表示されたことがきっかけです。 (試しにシークレットモードで入力してもサジェストされるので、私の検索履歴などのパーソナル情報によるバイアスはかかっていないはずです) 「Graphql オワコン」での検索結果TOPに「GraphQLはオワコンですか?これからはtRPCの時代ですか?REST APIの位置づけは何ですか?」というページがあったので読んでみました。 回答者はNodejsユーザグループ代表の古川さんで「GraphQLをオワコンと称するにはまだ早い」と回答されています。 私も
SaaS開発でもGraphQLを使いたい！
SaaSパーティショニングモデル まず、SaaS環境でテナントデータを分割するときには、一般的に使用される3つの基本モデル (サイロ、ブリッジ、プール) があります。 AWSでのマルチテナントストレージモデルの構築より 3つのモデルの詳しい解説については、ここ数年で多くの記事/議論が上がっており、ここでは詳しく解説しませんが、SaaSというビジネスモデル上カスタマイズ性と引き換えにコスト面/生産性を優先してプールモデルを選択することが多く、弊社でも同じくプールモデルを採用しています。 またプールモデルを実現するためのデータベース戦略として、OSSのDBの中ではPostgreSQLのRLS(Row Level Security)機能が唯一の選択肢であり、実質的にデファクトスタンダードとなっています。(OSSではないがOracleやSQLServerでもRLS機能を有している。) GraphQ
ハコベル物流DXシステム開発部のおおいし (@bicstone) です。普段はフロントエンドエンジニアとしてハコベル配車計画の開発を行なっています。 前回の記事では、GraphQLをプロダクトに投入するにあたり検討したエラーレスポンス設計パターンについて紹介しました。 この記事では、フロントエンドとバックエンド間でのバリデーションスキーマの取り決めについて解説します。 GraphQLスキーマ設計で悩まれている方の参考になれば幸いです。 はじめに ハコベル配車計画では、バックエンドとフロントエンド間の通信においてGraphQLを活用しています。1年ほど運用していく中で、設計における課題がいくつか表面化してきました。 今回、社内ハッカソンイベントHackWeek 2023 [1] が開催され、ハコベル配車計画チームでは1年間の運用の中で感じた、GraphQLスキーマの設計における悩みを振り返る
ユビーではNestJSでGraphQLのサーバー実装をおこなっています。今回は実践で得られた知見を元にNestJSでGraphQLのResolverに対してGraphQLのスキーマから生成したTypeScriptの型を適用する方法について解説します。 前提としてNestJSにはスキーマファーストとコードファーストがありますが、今回はスキーマファーストで書いたうえで、スキーマから型を生成するアプローチを紹介します。 NestJS組み込みの型生成を使う NestJSのスキーマファーストのアプローチではNestJSの組み込みの機能でスキーマからTypeScriptの型を生成することができます。 以下のように書くことで、 graphql.ts に型が生成されます。 GraphQLModule.forRoot<ApolloDriverConfig>({ driver: ApolloDriver, t
上記は、idとnameそしてroomをプロパティとして持つ、Hotelの型です。 nameが文字列型の必須のプロパティであり、roomというオブジェクトを複数持つことが簡潔に定義できます。 ちなみに、Roomの型は以下のように表現できます。 SDLは非常にシンプルで簡潔であるため、どのような言語を扱う技術者や非技術者でも理解しやすく、チームの枠を超えて、組織のデータモデルを定義するためのドキュメントとして機能します。 一方、欠点として、SDLにはfieldの値を計算して返すResolverの実装が含まれていません。 GraphQLを機能させるためには、何らかの言語でResolverの実装を追加で行わなくてはならず、GraphQLのみをSingle Source of Truthとすることはできません。 Code First Code Fistは、開発者はResolverだけを書くのみでよく
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Why, after 6 years, I’m over GraphQL
React Server Components と GraphQL のアナロジー
ネットスーパーアプリ GraphQL から REST へ移行始めました - every Tech Blog
TypeScriptとGraphQLで実現する型安全なAPI実装
TypeScript x GraphQLで2年開発してみて
GraphQL Gatewayはフロントエンド開発を幸せにする
GraphQLのよくないところ｜adwd
ソニー: GraphQLを活用したデータ配信プラットフォームの事例紹介
Fragment Composition of GraphQL
GraphQLをServer Componentsで使いたい
自作マークダウンパーサーとNext13+Prisma+GraphQL+Supabaseでブログを自作した
GraphQL 界の Babel こと Envelop を使ってスキーマの破壊的変更をごまかす
開発者フレンドリーは“ハッカーにとってもフレンドリー” 「GraphQL」の機能を使った悪用事例と究極の対策
GraphQLクライアントの技術選定 2023冬
GraphQLは「オワコン」「流行らない」のか？ - Qiita
【GraphQL】スキーマ駆動開発におけるバリデーションの取り決め設計パターン集
NestJSのGraphQL Resolver関数を型安全にしたい
GraphQL Server実装におけるSchema FirstとCode Firstの比較