tng23 でやったやつ
EngineeringThe GitHub GraphQL APIGitHub announced a public API one month after the site launched. We've evolved this platform through three versions, adhering to RFC standards and embracing new design patterns to provide a clear and consistent interface. GitHub announced a public API one month after the site launched. We’ve evolved this platform through three versions, adhering to RFC standards an
GraphQLやめました2020.05.27 当初Golang + GraphQLで作っていたAPIをRails + OpenAPIで作り直しました。なぜGraphQLで始めたのか、どうして作り直すことにしたのかなどを経緯とともにまとめました。 始まり弊社では qrop という農家さん向けのサービスを鋭意開発しています。 私はAPI等のバックエンドの開発を主に担当しており、このサービスの開発を始める段階でAPIは GraphQL にしよう、という話になりました。 GraphQL | A query language for your APIこの時点でGraphQLである必要性はなく、詳しいメンバーがいたわけでもなく、新しい技術に触れておきたいよねという程度の理由でした。 せっかくだしGolangで開発しよう、インフラはGCPにしよう、という具合にその時やりたいことを詰め込んで開発はスタート
グラフモデルとSoEとGraphQL / TECH STAND #7 GraphQL 2022/03/03 に行われた stand.fmさん主催の TECH STAND #7 にて上記のタイトルで登壇しました。 今回の内容は GraphQLの採用を検討するにあたって、RESTとの違い、BFFとの違いをデータの観点から言語化したかった Hasuraが良いという意見と, Apolloやgraphql-ruby, gqlgenなどのハンドライティングなGraphQLが良いという意見の違いがどこから生まれているかの考察がしたかった データ指向アプリケーションデザイン(2017年リリース)にSoEやGraphQLへの言及がないため, 今だとこういう内容が書かれているんじゃないかという考察がしたかった をモチベーションに調査・検討しました。 発表のハイライトはこちらです。 以下発表内容です。一部発表時
今個人で作ってるアプリの 認証 + Graphql の部分を抜き出して GitHub に公開した。 mizchi/next-boilerplate-20200727 next.js + vercel + firebase は (パーツを良く選べば) 最高 next.js はルーティングを持つページを作るには最高で、サーバー、静的サイト、JAM スタック、AMP と必要に応じて選択できる。React ベースならこれ一択。 認証サーバーの実装は毎度疲れるし、Firebase Athunetication はこの点においては OAuth Secret を置くだけ + Custom Provider も作れるので、最高。 それと比べて firestore は、ちょっと前に firestore べったりでアプリを試作したことがあったのだが、型がないためにかなり扱いづらく、また読み書きの速度が遅くパフ
追記: 2021年6月現在はアーキテクチャが変わってきています。 次の記事に詳細を書いていますので、一読をお願いします。 Kaizen Adのフロントエンドアーキテクチャの遷移について - Kaizen Platform 開発者ブログ Kaizen Platform でフロントエンドエンジニアをしている山本です。この記事では、我々が運営するサービス「Kaizen Ad」のフロントエンド部分をご紹介します。 Kaizen Ad とは Kaizen Ad は、動画広告をサポートするマーケットプレイスです。 カスタマーがクリエイティブを依頼すると、広告クリエイティブを作成するグロースハッカーから動画広告クリエイティブが納品される仕組みです。 カスタマーにとってはクリエイティブ改善の運用を省力化できると同時に、グロースハッカーにとっても新しい働き方が創造できるソリューションとして提供しています。
記事の概要 この記事は、Meta 社 relay.dev チームの Jordan Eldredge 氏の Tweet で紹介された GraphQL 成熟度モデル (GraphQL maturity model) を個人的な見解を加えながら和訳した記事です。 jordaneldredge.com GraphQL を実装する上で、どの程度 GraphQL を使いこなせているか判断するための参考になれば幸いです。 実際の成熟度モデルの和訳 最初の Tweet 私は、GraphQLの利点がまだ十分には理解されていないと思っています。ほとんどの組織では、GraphQL の提供する価値を捉えきれていません。 そこで、私は「GraphQL成熟度モデル」をスケッチしてみました。あなたの組織はどの程度成熟して(=使いこなせて)いますか? もし以下に示す13の成熟度を達成していたとしたら、よりGraphQLを
技術部の外村(@hokaccha)です。 レシピサービスのフロントエンドを Next.js と GraphQL のシステムに置き換えている話 - クックパッド開発者ブログ という記事を書きましたが、この中で詳しく説明しなかった GraphQL のスキーマやクエリから TypeScript の型定義を自動生成する仕組みについて紹介します。 なお、今回紹介したコードは以下で試せます。 https://github.com/hokaccha/graphql-codegen-example-for-techlife GraphQL Code Generator を使った型生成 GraphQL のスキーマから TypeScript の型を生成するためのライブラリはいくつかあります。 Apollo GraphQL Code Generator などが有名どころです。今回はシンプルさや拡張性を考えて G
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 API をインターネットに公開する際は、悪意あるクエリに対する防衛が欠かせません。この記事における「悪意あるクエリ」とはサービスに意図的に負荷をかけるクエリのことです。GraphQL では 、木構造や再帰的な構造を利用して、一回のクエリで容易に数百万・数千万件のデータを取得することができます。そのようなクエリを実行してしまうと、アプリケーションサーバーや、その後ろにいる別のサービスに甚大な負荷がかかります。これは攻撃者からしてみれば恰好の的で、なんらか対策を講じる必要があります。 幸いこうした問題はよく知られており、クエリを静的に解析するライブラリがいくつか存在します。しかし、そうしたライブラリをどう使うかといったことはあまり議論されておらず、効果的な対策を行うのは依然として難しい状況だと感じます。この記事では、典型的な負荷の高いクエリとその具体的な対策を紹介
こんにちは、サーバーサイドエンジニアの竹若です。今回GraphQLにおけるエラーハンドリングを調査、Ruby on Railsとgraphql-rubyを使って実装する機会があったので、そこで得られた知見を共有させていただきたいと思います。(なお今回の実装はプロダクション環境には出ていません) GraphQLの仕様とプラクティス それではまず初めに、GraphQLが仕様に定めているレスポンスの返し方を見ていきましょう。 レスポンスのフォーマットに関するプラクティス GraphQLのプラクティスの1つに、レスポンスのhttp statusを200で統一し、レスポンスのerrorsキーにエラーの詳細な情報を持たせるというものがあります。 なぜならGraphQLではリクエストに複数のクエリを含めることができるからです。 https://www.graph.cool/docs/faq/api-ee
tl;drNext.jsはv9.3.0以降Initial Loadingの扱いが変わったクライアント側ではApolloを利用することができるが、Authorization Headerを設定するなら一工夫必要SSR時にはfetchによるシンプルなAPIリクエストをすると良い昨今のWebフロントエンド昨今のWeb開発において、React、TypeScriptとかのベース知識は当然として、やはりNext.js(あるいはNuxt.js)のような、SPA/SSR両方のニーズを汲み取りながら、dynamic routingを提供してくれたり、ビルド環境を高速に整備してくれるフレームワークが重宝されるようになってきていると感じます。 また、Reduxもアリですが、スキーマ駆動開発が推進できるGraphQL、特に尋常じゃなくステート管理が用意になるHooksとApolloクライアントの組み合わせは、フロ
本文書は、 Kibela Web API の実装についてのスタイルガイドです。 実装の原則 GraphQL official site に従う GraphQLに足りない部分は Relay server specに従う 実例としてはGraphQL+Relayで構築されているGitHub API v4を参考にする Naming フィールド名 ※ graphql-ruby 1.8 以降は自動的にcamelizeされるようになっているので、任せましょう。 camelCase にしてください。 定義の際にmodel本来の名前と変える必要がありますが、クライアントサイド言語(JS, Swift, Java)はcamel caseが基本なので、そのまま使えるというメリットがあります。 なお camel case はいくつかのバリエーションがありますが ActiveSupport の String#cam
はじめに マイクロサービスの開発では、サービスが増え続けるバックエンドに対して、フロントエンドは接続先が増えるため、開発効率を下げてしまいます。その対策として、さまざまな設計パターンが存在します。 弊社の開発ではGraphQL Gatewayを用いていますが、そこに至るまでや周辺の技術/アーキテクチャを解説します。 マイクロサービスとフロントエンド マイクロサービスを採用する場合、フロントエンド(ウェブアプリケーション、モバイルアプリケーションなど)は複数のサービスとの連携が必要になることが多いです。各マイクロサービスは通常、API(REST、gRPCなど)を提供し、フロントエンドはこれらのAPIを通じてデータの取得や操作を行います。 API Gateway API Gatewayは、フロントエンドとマイクロサービス間の中間に位置するコンポーネントとして機能し、マイクロサービスアーキテクチ
k0kubun.hatenablog.com 非常に丁寧に書かれていると思うのですが、少し反論したい部分があるので、記載したいと思います。 GraphQLのキャッシュ効率について クエリをパースしないとキャッシュの可否を判定できないため、HTTPキャッシュが難しい こちらに関して、2つの観点から反論してみたいと思います。 まずに、GraphQL は GET リクエストでも送ることができます。Serving over HTTP | GraphQL によると、http://myapi/graphql?query={me{name}} のような URL の GET リクエストができます。(※そもそも、これ自体は GraphQL の絶対的な制約ではなく、 GraphQL を一般的に HTTP で提供するときのプラクティス、という位置づけです) そして、GraphQL は 1 回のリクエストで送らな
id:gfxです。 RejectKaigi 2017で「GraphQL on Rails」という発表をしました。 当日はKibelaでプレゼンテーションをしたので、それをそのまま資料として発表します。 2017/08/19 at Speee, Roppongi. 自己紹介 Kibelaという情報共有サービスを開発している Kibelaの公開Web APIをフルスクラッチするにあたってGraphQLを調べているところ 自分のOSSを誰かに引き継いだり共同開発体制にしていたら、GitHubのpinned reposがすべてorganizationのものになった 本日の話 GraphQLとは GraphQLをRailsに組み込む話 GraphQLとは Web API のためのクエリ言語 http://graphql.org/ RESTful API の次を狙うWeb APIアーキテクチャという位
こんにちは。エンタメ領域のDXを推進するブロックチェーンスタートアップ、Gaudiyでエンジニアをしている高島(@takashima_katsu)です。 Gaudiyでは現在、BFFレイヤとしてGraphQLサーバを利用しています。導入してから1年以上が経ちますが、スキーマ駆動開発はDXの向上につながっていると実感しています。(以下のブログが詳しいです。) techblog.gaudiy.com 今回は、GraphQLの利点を活かしたエラーハンドリングの方法について、Gaudiyでの実践をもとに書いてみたいと思います。エラーハンドリングの実装について課題感のある人や、現在GraphQL Errorsを使っている人に、ぜひ読んでいただけると嬉しいです。 1. エラーハンドリングとGraphQL 2. GraphQL Errorsにおける課題 3. GraphQLエラーハンドリングの実践 3-
こんにちは。武田(@tkdn)です。 GraphQL を API として採用したサービスを今年序盤にリリースしています。具体的な内容は今年の夏サミ 2020 の公募枠でお話させていただいたのでよろしければ資料もご参考ください。 週一でリリースし続けるためのフロントエンドにおける不確実性との戦い方 / Developers Summit 2020 Summer C-4 - Speaker Deck今日は GraphQL や Apollo Server についての振り返りと反省を中心に供養しておきます。GraphQL 採用に迷いがある開発者、Apollo Server を採用しようとしている開発者へ向けた知見になれば幸いです。 まとめてみたら GraphQL みが思いの外少なくなりましたが、GraphQL Advent Calendar 2020 の 23 日目の記事です。 なぜ GraphQ
GraphQL Tokyo #10 Links: p11 https://speakerdeck.com/qsona/graphql-for-service-to-service-communication-protocol p12 https://note.com/qsona/n/nfc73a8e82dff p14 https://speakerdeck.com/qsona/graphql-changing-and-unchanging p23, p28 https://www.apollographql.com/docs/apollo-server/features/schema-stitching/ p30, p31 https://www.apollographql.com/docs/apollo-server/federation/introduction/ p33 https:
「Mix Leap Study」はヤフーの独自技術や業界の最先端テクノロジーに触れる勉強会。第59回は「React とその仲間たち」と題して、より実践的にReactを使うための仲間たちにも注目。株式会社Gemcookの藤本卓哉氏が、プロジェクトにGraphQLを採用してみた経験から、いい点、悪い点を語ります。 React + GraphQLで社内の負債を解決した話 藤本卓哉氏:みなさん、こんばんは。ジェムクックの藤本です。『React + GraphQLで社内の負債を解決した話』というタイトルでお話ししたいと思います。よろしくお願いします。 まず簡単にプロフィールです。藤本卓哉と言います。去年(2019年)30歳になって、今年(2020年)31になります。会社の代表兼エンジニアをやっています。会社の代表といったら、経営ガッツリやっているんかなって言われがちなんですけど、僕けっこうエンジニア
春の入門祭りの7日目です。 はじめに※このエントリーはGoでGraphQLサーバアプリ開発の入門記事です。技術要素にGo, gqlgen, Docker, PosgreSQLなどが登場します。 TIG DXユニット 1の真野です。技術ブログ運営もしています。 フューチャーではOpenAPI関連の過去記事からお察しもできるように、REST-likeなWebAPIを実装することが多いです。しかし日本製HeadlessCMSのmicroCMSを触ってみたの記事で紹介されたように、HeadlessCMS界隈を初めGraphQLのAPIを提供するサービスが増えている体感もあり、GraphQLを春の入門祭りのテーマにしました。 学習する上でドキュメントを読み込むだけでは忘れがちです。手を動かしながらタイトルにあるように鉄道データ検索APIをGraphQLで実装していきましょう。実装の前に結果のみを知り
A Jamstack framework for Vue.js Gridsome makes it easy for developers to build static generated websites & apps that are fast by default 🚀 Get started Open-source MIT Licensed. GitHub (v0.7.23) CMSsAny Headless CMS, Contentful, WordPress, Drupal, Sanity.io, etc. DataAny APIs, Databases, AirTable, YAML, CSV, JSON, etc. MarkdownAny Git-based CMS, Forestry, Netlify CMS, Blogs, Documentation.
Slack botが更新する研究室のHPを作りました。 できたもの https://moriokalab.com Slack botが動いている様子 なぜ作ることになったか 〜ある日〜 指導教員「研究室のHPが欲しいから作って。何も管理したくないからWordPressとかCMSはいやだ。Slackから投稿出来るようにしたい。」 後輩くん「分かりました」 〜その後〜 後輩くん「先輩・・・お願いします・・・」 俺「任せろ」 こうして我々はHPを作ることになった。 要件整理 使う技術を決める前に、まずは頂いた要件を整理します。 webページを作る 動的に変更されるコンテンツがある データのリレーションは特になし サーバーやパスワードとか、何も管理したくない 研究室のみんなで更新したい Slackからアップデートできるようにしたい なるほど。どう作るかぼんやりと見えてきました。 構成を考える まず
こんにちは、JapanTaxi SREチームの水戸です。 インフラからアプリケーションまでサービスの安定性向上のための改善を日々行っています。 今年9月のリニューアルで、JapanTaxiアプリ向けのAPIにGraphQLを導入しました。この記事では実際にGraphQL導入したことで感じたメリットと課題を書いていきたいと思います。 現在のJapanTaxiアプリにおけるGraphQLの導入状況 今回は数年間開発を続けてきたアプリのリニューアルプロジェクトということで、既存部分を使いまわしている部分も多々あり全てのAPIを一斉に置き換えるのは難しい状況でした。そのためリリース時点ではアプリの変更に合わせて改修が必要になった参照系のAPIにのみGraphQLを導入しました。 リリース後は順次RESTからGraphQLに切り替えを進めており、一部では更新系でもGraphQLを使い始めています。
■ご案内■ 本連載の背景/作成できるアプリケーション/進め方をご理解頂く上でも【環境構築編】 をご一読頂けると幸いです。 【環境構築編】 【Next.js編】 【Go編】 👈いまここです 【AWS編】 これからも頑張ってハンズオン系の記事を書いていきたいと思っているので、いいねっと思って頂けたらLGTM押していただけると励みになります! 環境構築 本サンプルアプリの環境構築方法は【環境構築編】に記載しているので、そちらをご参照ください。 クリーンアーキテクチャ風なディレクトリ設計 以下の記事を参考にしつつクリーンアーキテクチャ風なディレクトリ設計をしてみました。 各階層間をインターフェースを利用して、システムの各部分を疎結合化しております。 # 簡単のため一部ファイルは割愛しています go-graphql-jwt-api/ ├── build/ │ ├── db/ │ └── dock
Build GraphQL APIs you can trust Learn how to design and build predictable, performant, and secure GraphQL APIs at scale. Hey 👋 I'm Marc-Andre Giroux! I've always found there was a lack of resources on how to build reliable GraphQL servers. Over the last few years, I helped build and maintain some of the biggest GraphQL APIs out there at both Shopify and GitHub. During those years, I also worked
関連キーワード API | データ統合 前編「Netflixがクエリ言語『GraphQL』を採用 何にどう使っているのか」は、Netflixのコンテンツエンジニアリングチームに所属するギャレット・ハインレン氏が、同チームで使うデータ連携用のクエリ(データ操作)言語として「GraphQL」を採用した背景を説明した。一方でハインレン氏のチームは、依然としてスキーマ管理、エラー処理、分散書き込みなどの問題に直面している。「GraphQLはクエリとAPI(アプリケーションプログラミングインタフェース)構築のプロセスを簡略化するが、特効薬ではない」と同氏は言う。 ハインレン氏はGraphQLを受け入れるまでに数カ月を要した。受け入れた理由は、テクノロジー面でのメリットがあるからというよりも「チームと組織の行動やコミュニケーションを改善するためだった」と同氏は明かす。同氏によればGraphQLは、スキ
Backends for Frontends的に、1画面につき1つずつAPIを作っていると、画面のリストを作って、それぞれ1画面につき1個ずつAPIを作っていくことになるので、進捗の把握がやりやすかった。10画面あって3APIできてたら進捗30%ということになる。 グラフをたどって開発することになる GraphQLでAPIを作っていると、「実はこの画面を組み立てるためのクエリは、あちらの画面の条件を変えたものである」みたいなことが起きるようになる。たとえば、トップページではサマリを表示していて、もっと見るを押すと全件表示するような場合とか。 このように、着手しようとするともう作るものがなかったりとか、逆に、作るときに、他の画面から使う想定でパラメータの設計をするなど、考えることが増えたりもする。 スキーマに沿ってグラフをたどるだけで画面を組み立てられるのは良いことだけど、開発内容の依存関係
この記事はGraphQL Advent Calendar 2021の22日目の記事です。 またこれは書籍、出来る100%TypeScript 作って学ぶNext.js + GraphQL + Prismaに掲載していたコラムに加筆修正を行ったものです。 GraphQLは一言でまとめてしまえばDSL(GraphQL query language)による宣言的な記述を介してGraphQLサーバーから柔軟にデータを取得/提供する事が出来る仕組みです。文法は全く異なりますが動作モデルとしてはSQLとRDBの関係に近いかもしれません。なおHTTP上で利用される事がほとんどですが特に決まりがあるわけではありません。 元々はFacebook社(現Meta社)で開発され2012年からfacebook.comで利用されている技術で、その後2015年にはオープンソース化されFacebook以外でも徐々に利用さ
これは 6/28 に開催される GraphQL ナイト のための資料です ここまでで分かること クエリは独自言語みたい クエリを変えることで柔軟にデータをとってこれそう クエリと結果の見た目が似てるのは分かりやすそう(主観) でも facebook はなんで作ったの? facebook の事情 数十億ユーザから膨大なリクエストがくる 新興国の低速なネットワークからのモバイル接続も多い アップデートされないモバイルアプリもサポートする つまり リクエスト回数は可能な限り減らしたい 後方互換を維持しながら API を開発したい 無駄なデータを送りたくない (大規模開発なので型安全も欲しい) 規模は違えど我々も同じような問題を抱えているのでは? なぜ既存のものではダメだったのか? より詳しくは昔の graphql.org のページを参照(internet archive) v.s. REST 複
この記事では、GraphQL を利用したアプリを Next.js で構築していきながら、GraphQL の初歩について書いていく。 GraphQL のクライアントもサーバも、Apollo を用いる。 また、できるだけ型安全に開発したいので、graphql-codegenで型定義ファイルを生成する方法も扱う。 利用しているライブラリのバージョンは以下の通り。 @apollo/client@3.5.10 @graphql-codegen/cli@2.6.2 @graphql-codegen/typed-document-node@2.2.7 @graphql-codegen/typescript-operations@2.3.4 @graphql-codegen/typescript-resolvers@2.5.4 @graphql-codegen/typescript@2.4.7 @type
GraphQL Edge CachingReduce origin traffic and boost performance by caching GraphQL queries. GraphQL MetricsWith no configuration, get real-time observability for your GraphQL APIs usage, performance and errors. GraphQL SecurityProtect your GraphQL API from scrapers, traffic or infrastructure costs spikes, and broken SLA terms.
AWS AppSyncが一般公開されました AWS re:Invent 2017で発表された、モバイルアプリのための期待のマネージドGraphQLサービス「AWS AppSync」。本日ついに一般公開(GA)されました! AWS AppSync now Generally Available (GA) with new GraphQL Features AWS AppSyncとは? AWS AppSyncは、クロスプラットフォームでデータのリアルタイム同期を行うためのGraphQLをベースとしたアプリケーションのバックエンドを提供するサービスです。次の機能を利用できます。 リアルタイムアプリケーションの作成 同期を使ったオフラインプログラミングモデルの構築 必要なデータだけ GraphQL で取得 複数のデータソース(Amazon DynamoDB、Amazon Elasticsearch
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く