今更ながら graphql-code-generator の便利さを痛感する - Qiita
はじめに 今日も今日とて、フロントReact + バックRailsのSPA + APIのアプリ開発していたところ TypeScriptのReact側で、react-apolloの型宣言がめんどくさいと思っていました。 バックエンド側はGraphQLを使用しているので、いろんなところに型宣言をしているようにも感じて、微妙。。 そこでgraphql-code-generatorを使っていろいろ気持ち悪い部分を解消していこうという話をします。 今回の構成 フロントエンド GitHub React（SPAで） TypeScript create-react-app React Apollo バックエンド GitHub Ruby Rails（APIで） GraphQL ※上記２つのリポジトリはこちらのリポジトリから連動させる仕組みとしました。（開発環境として） とりあえずApolloの公式通りにやっ
GraphQLライブラリをApollo→Relay→Urqlにハシゴした話 | 株式会社ヌーラボ(Nulab inc.)
GraphQLクライアントライブラリ乗り換え遍歴 私達のプロジェクトではReactのフロントエンドとバックエンドの通信にGraphQLを使っています。 GraphQLは、たいていの場合はHTTP POSTリクエストで リクエストボディ：GraphQLクエリ（文字列）と引数（オブジェクト）からなるJSON レスポンスボディ：データJSON をやりとりするだけというだけのシンプルなプロトコルなので、全てfetch関数で頑張るストロングスタイルで行けないこともないですが、やっぱり専用のクライアントライブラリを利用したほうが楽です。 そのライブラリとして一番有名なApollo Clientから始まってRelay、Urqlと、3ヶ月くらいの間に2回も乗り換えてしまったので、反省の意味も込めて記事にしたいと思います。 GraphQLクライアントライブラリがいろいろあってどう違うんだろうと迷った方の助け
Rails GraphQL
Install Totally plug-in-play # Add the gem to your Gemfile $ bundle add rails-graphql # Then run the Rails generator $ rails g graphql:install Define Designed for simple and complex Schemas # app/graphql/app_schema.rb class GraphQL::AppSchema < GraphQL::Schema field(:welcome).resolve { 'Hello World!' } end Run Follows Rails core principles $ curl -d '{"query":"{ welcome }"}' \ -H "Content-Type: ap
いかにして GraphQL を組織に導入するか (新規開発編) / how we introduce GraphQL on scratch development
GraphQL Tokyo #18 Lightning Talks https://www.meetup.com/ja-JP/graphql-tokyo/events/286913987/ Links: [GraphQL を活用したスキーマ駆動開発の実践](https://speakerdeck.com/qsona/schema-driven-development-with-graphql) [GraphQL を利用したアーキテクチャの勘所 / Architecture practices with GraphQL - Speaker Deck](https://speakerdeck.com/qsona/architecture-practices-with-graphql) [Quramy/gql-study-workshop](https://github.com/Quramy/g
脱Firestoreするために考えていること（追記あり） - Sweet Escape
FirebaseのFirestoreをやめることにしたので雑なメモを残しておく。なお、まだ走り始めたばかりなので、内容には間違いや考慮不足も多数含まれる可能性があるので読む人はその点注意を。あと、あくまでも雑なメモなので細かいところは書いていない。 なぜ脱Firestoreするのか？ なぜGraphQLではなくREST APIなのか？ 移行にあたって検討したこと、決め事 ドキュメントIDをどう扱うか サブコレクションをどう扱うか 配列やマップといったフィールドのタイプをどう扱うか 追記: Mapの配列をどうするか Firebase Authenticationとセキュリティルールで実現しているセキュリティ機能をどうするか では実際にどんなテーブル設計にするのか 次にやること なぜ脱Firestoreするのか？ まず、脱Firestoreする理由は ユースケースとしてFirestoreでは対
あなたのプロダクトに 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 などほかのクライアントと比べ圧倒的です。 実際、一休
graphqlクライアントの Altairでトークン認証を行う方法 - その辺にいるWebエンジニアの備忘録
こんにちは！kossyです！ さて、今回はgraphql-ruby + Rails APIモードでdevise_token_authを用いてトークン認証する開発において、 Altairを使ってトークン認証をパスする方法についてブログに残してみたいと思います。 環境 Rails 6.0.3.4 Ruby 2.6.3 MacOS Catalina なお、devise + devise_token_auth で Userモデルを作成し、 CORSの設定やマイグレーション周りの設定が済んでいるものとします。 devise + devise_token_auth のセットアップ手順はこちらの記事が詳しかったです。 トークン認証だとgraphiql使えない トークン認証を利用している時にgraphiqlを使う方法をググってもHackしたやり方しか出てこなかった(jsでXHR送るみたいな、、、)ので、
pg_graphql: A GraphQL extension for PostgreSQL
We found both options to be largely viable for the core feature set. Which left us with one final hang-up: we host free-tier projects on VMs with 1 GB of memory. After tallying the resources reserved for PostgreSQL, PostgREST, Kong, GoTrue, and a handful of smaller services, we were left with a total memory budget of ... 0 MB 😬. Unsurprisingly, our pathological memory target disqualified any opti
TypeScript * GraphQLのバックエンド設計プラクティス
2冊目も公開中なのでみてください！ https://zenn.dev/tatta/books/4e993c596e7dc9 TypeScriptを使いはじめて1年になるので、バックエンドのWebアプリを設計するときに気を付けていることをまとめました。（※社内勉強会用資料の公開版です。） TypeScriptについては、Next.jsを中心にフロントエンドに関する公開情報が豊富です。一方でバックエンドに関する公開情報が少ないと感じています。（かくいう私もNext.jsからTypeScriptデビューしたわけですが） TypeScript * GraphQL という構成は仕事・趣味で採用されている方も多いのではないでしょうか？ 私もその1人です。私のような方のためにも、バックエンドの設計プラクティスについてまとめようと思い筆を取りました。 本書がこれから始める読者にとっては教科書のようになり、
Apollo Federation で GraphQL マイクロサービスアーキテクチャを構築する
最近調べていた Apollo Federation についてのメモです。 Apollo Federation の概要と、Next.js の API Routes で Apollo Federation を使う例をまとめています。 Apollo Federationとは？ 以前 Netflix の GraphQL マイクロサービスアーキテクチャが話題になりました。その構成を支えているのが Apollo Federation です。 Apollo Federation は、複数の GraphQL マイクロサービスをゲートウェイでまとめて、1 つの GraphQL エンドポイントとして提供するものです。 Apollo Federation を使うことで、それぞれのマイクロサービス間で依存する処理を良い感じに統合してくれます。 例えば、投稿情報は Post マイクロサービスにあり、その投稿の投稿者
How to GraphQL with Ruby, Rails, Active Record, and no N+1—Martian Chronicles, Evil Martians’ team blog
You work on a mature web application that cleanly separates backend and frontend. The server-side code, written in Ruby, is mostly responsible for translating HTTP requests into SQL statements (with the help of an ORM) through rich and well-documented API. You choose GraphQL over REST to streamline your endpoints, but your database is not happy with all the extra queries. After much searching, you
GraphQL API Security with AWS AppSync and Amplify | Amazon Web Services
Front-End Web & Mobile GraphQL API Security with AWS AppSync and Amplify This article was written by Brice Pellé, Principal Specialist Solutions Architect, AWS September 14, 2021: Amazon Elasticsearch Service has been renamed to Amazon OpenSearch Service. See details. AWS AppSync is a fully managed service which allows to deploy and interact with serverless scalable GraphQL backends on AWS. AppSyn
GraphQLはサーバーサイド実装のベストプラクティスとなるか - Qiita
この記事は GraphQL Advent Calendar 2020 14 日目の記事です。 前回の記事は @joe-re さんの 「ライブラリの実装からCursor-based paginationにおけるcursorのフォーマットのベストプラクティスを探る」 でした。 前置き GraphQLは2010年代後半に出てきた技術の中でも個人的に特に強力なアプリケーション実装パターンの一つだと思っているのですが、シンプルな実装なのに利用用途が豊富にあることと利用する立場が違うと全く印象を抱く事から全体像を掴みづらく、本来持つべきポテンシャルに対してまだ認知が広がっておらず利用されていないように感じます。 今回はサーバーサイドからの視点を中心にGraphQLを構築する要素を分解して解説するのとともに、それを利用した際にWebアプリケーション開発やそれに関わるエンジニアに起きうる変化について書いて
How Netflix Scales its API with GraphQL Federation (Part 2)
In our previous post and QConPlus talk, we discussed GraphQL Federation as a solution for distributing our GraphQL schema and implementation. In this post, we shift our attention to what is needed to run a federated GraphQL platform successfully — from our journey implementing it to lessons learned. Our Journey so FarOver the past year, we’ve implemented the core infrastructure pieces necessary fo
レシピサービスのフロントエンドを Next.js と GraphQL のシステムに置き換えている話 - クックパッド開発者ブログ
技術部の外村（@hokaccha）です。今回はクックパッドのウェブサイトのフロントエンドを Next.js などを使って作り直している話を書きます。 この記事で紹介する新システムは、スマートフォン向けのレシピページで確認することができます。もし興味があるかたはレシピページをスマートフォンのユーザーエージェントで開いて DevTools などで確認してみてください。 Next.js と GraphQL で動いているのがわかると思います。 ご存じの方も多いかもしれませんが、クックパッドのウェブサイトはモノリシックな Rails で作られていて、10年以上 Rails で開発を続けてきました。10 年以上同じシステムで開発を重ねれば当然レガシーな部分が大量に生まれてきますが、特にフロントエンドはその影響が顕著でした。 どこから使われているかわからない CSS が大量にある、JS のコードは昔なが
Integrity Principles
Integrity PrinciplesEnsuring that the graph is well-defined, stable, and consistent 1. One Graph Your company should have one unified graph, instead of multiple graphs created by each team. By having one graph, you maximize the value of GraphQL: More data and services can be accessed from a single query Code, queries, skills, and experience are portable across teams One central catalog of all avai
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GraphQL ❤️ Sorbet and Unit Tests
Integrating GraphQL and SQL with AWS AppSync, AWS Lambda and Amazon RDS Proxy | Amazon Web Services
How I built a social network in 4 weeks with GraphQL and serverless
Prisma2 with Graphql
