はじめてのGraphQLスキーマ設計GraphQLのよいスキーマ設計についてです。
GraphQLとRESTfulについて今日考えてたこと Backend for Usecase/Resourceについて - 余白
DISCLAIMER: これは本当にただのメモ書きで、これがベストプラクティスだとかいう話ではないので、同じようなことを考えてる人いたら今度議論しましょうよ、って程度の話の種。 GraphQLを使うべきスポット、RESTfulが好ましいスポットについて今日ぼんやり考えていて、なんとなく言語化ができる気がするので文字起こししてみる。 Backend for UsecaseとBackend for Resource バックエンドのAPIには2種類あって、 「データ」を構成する「リソース」を提供するもの アプリケーションの「ユースケース」がもつシナリオのなかで登場する「データ」部分を埋めるためのもの を区別することが必要そう、と思っている。 まず前者を Backend for Resource (BFR)と呼ぶことにする。これはわかりやすくて、これはまさしくRESTfulそのもの。 RDBやそう
Thinking in Relay | Relay
Relay's approach to data-fetching is heavily inspired by our experience with React. In particular, React breaks complex interfaces into reusable components, allowing developers to reason about discrete units of an application in isolation, and reducing the coupling between disparate parts of an application. Even more important is that these components are declarative: they allow developers to spec
GraphQLナイトに参加した & 『GraphQLとスキーマファースト開発』についてLTした - kymmt
connpass.com 五反田のfreeeさんでGraphQLナイトが開催されたので参加してきました。会社のSlackの開発者チャンネルで@hsbtさんが貼ったリンクを見て開催に気づけたので、ありがたい限りでした。 また、LT枠が急遽空いたので、前日に飛び入りでLTすることに決めました。LT資料はこちらです。 内容としては、これまでの記事から、あまり他の人と被りなくRubyに特化しすぎることもない次のネタをあらためて紹介した感じです。 blog.kymmt.com どういう反応になりそうかあんまりわからなかったのですが、ある程度こういう話に興味がある人は多いのかな？という感想でした。 先程のLT資料です #gqnight https://t.co/CfwNOkd0GZ— kymmt90 (@kymmt90) June 28, 2018 あと、いい機会なのでサンプルを作りました。 gith
世のフロントエンドエンジニアにApollo Clientを布教したい - Qiita
こんにちは。いかがコーディングお過ごしでしょうか。 私は今更ながら最近GraphQLで遊び出し、そしてApollo Clientに出会いました。 ワクワクしました。「これは想像以上に既存のフロントエンドの設計・実装を変えるものだぞ！」と感じました。 「Apollo ClientってGraphQLクライアントでしょ？GraphQLエンドポイントない俺には関係ないな。」と思ったそこのあなた、それだけじゃないんですApollo Clientは！！！！！ 本記事では「Apollo Clientとはなんぞや」という話と「なぜ私がApollo Clientを布教したいのか」という点について語ります。実は最初は実装含めたチュートリアルを書いていたのですが長くなり過ぎたため記事を二つに分けました。この記事はどちらかと言うと概念系の話が多めで、片方にApollo Client + Reactのチュートリアル
GraphQLはRESTの置き換えではない｜こんぴゅ
GraphQLは最近注目されているWeb APIのための問い合わせ言語だ。 現在主流のRESTfulなAPIはURLとmethodでリソースを表現するわけだが、GraphQLは単一エンドポイント（ex: "POST /graphql"）だけ存在し、欲しいリソースをHTTP POSTのbodyに明示的に記載してリクエストする。 ↑JSON APIをGraphQLの形式でコールする（引用: how to graphql ) 徐々に実装例が増えてきており、2016年にはGithubがAPIの実装を全面的にGraphQLに移行させたのが注目された。 色々調べていくと、GraphQLは単にRESTの代替ではなく、開発・運用フローを一新させうるほど豊かな思想・機能を含む事が分かって来たので現状の整理をしてみたい。 APIリクエストを束ねて効率化RESTではURLがひとつのリソースを表すため、複数のリソ
GraphQLやってる - mmag
前に書いた社内向けの日報Webサービスで、RESTful(RESTish?)なAPIからGraphQLなAPIに書き直しをしてる。 サーバ側 そもそもそんなに大きなアプリケーションではないので、雑にhas manyやらassociationsを辿っていく程度のものはすぐにできた。認証はAuthorizationヘッダにJWTをつけてる。ちょっと前にブログ書いたはずと思ったら3ヶ月近く前で震えた。 joe-noh.hatenablog.com Root Fieldとしてはuserとnippoesを用意。userはユーザ名を引数に取る。nippoesは日付と順序を受け付けて日報のリストを返す。こんなクエリをイメージしていた。 query ($name: String!, $date: String!) { user (name: $name) { nippoes (date: $date, o
GraphQLを使ったアプリケーションがリリースされたので勘所を考えた - Feedforce Developer Blog
小飼です。Dropbox上場のニュースをみて『Rustで上場』という標語を考えたんですが、ロジックが乱暴過ぎるとの評価を頂きました。 さて、フィードフォースでは去る3月8日広告出稿・運用支援ツール『EC Booster』をリリースしました。 この新サービスにはクライアント・サーバ間コミュニケーションのインターフェースにGraphQLを採用しています。 GitHub, Apolloなど、海外では採用事例の増えてきている印象のあるGraphQLですが、国内における採用事例はまだあまり多くはないようです。 そこで本稿では、フィードフォースで実際のプロダクションに採用してみての、初期の使用感などをお伝えしたいと思います。 なお、本アプリケーションはAPIサーバ及びアセット配信サーバとしてのRailsアプリケーションが、 React/Apolloで構築されたクライアント側アプリケーションと、Grap
GraphQL APIをスキーマファースト開発するためのモックサーバをRailsとApolloで作る - kymmt
GMOペパボ Advent Calendar 2017の23日目の記事です。 今回はJavaScriptでGraphQLのサーバ／クライアントや関連ツールを提供しているApolloのツールセットでRailsプロジェクトでGraphQLのモックサーバを立ち上げるところまでを試してみます。 業務でRails製の（RESTishな）Web APIとVue.js製のSPAからなるアプリケーションを開発していて、スキーマファースト開発を取り入れています。また、GraphQLで通信するAPIを実験的に導入しはじめていますが、こちらは明示的な開発フローを決めず導入しようとしているため、なかなかサクサクと開発が進まないのが現状です。そこで、GraphQLでも先にインタフェースだけを決めてから、モックサーバを使ってフロントエンドとバックエンドで並行開発していけばよいのでは、という発想になります。 しかし、そ
「GraphQLは何に向いているか」に対してのちょっとした反論 - 病みつきエンジニアブログ
k0kubun.hatenablog.com 非常に丁寧に書かれていると思うのですが、少し反論したい部分があるので、記載したいと思います。 GraphQLのキャッシュ効率について クエリをパースしないとキャッシュの可否を判定できないため、HTTPキャッシュが難しい こちらに関して、２つの観点から反論してみたいと思います。 まずに、GraphQL は GET リクエストでも送ることができます。Serving over HTTP | GraphQL によると、http://myapi/graphql?query={me{name}} のような URL の GET リクエストができます。(※そもそも、これ自体は GraphQL の絶対的な制約ではなく、 GraphQL を一般的に HTTP で提供するときのプラクティス、という位置づけです) そして、GraphQL は 1 回のリクエストで送らな
Rails + GraphQL で REST じゃない API を作る - まっしろけっけ
はじめに ここに書いている内容は僕が仕事で開発を行なっている minne の API に GraphQL を導入するにあたり gist に雑にまとめてメンバーに共有した内容で公開できない部分をアレしたやつです。 (minne の API は現状オープンなものではないです。 GraphQL #とは プログラミング言語ではなく、クエリ言語 GraphQL というミドルウェアでは無い 専用の server を立てるとかも必要ない 開発は FB GraphQL 標準化を目指して Draft RFC が公開されている メリット クライアントが必要とするデータを 1 回のリクエストで取得できるようになる REST に近い API だとモバイルアプリで 1 画面を表示するために複数回のリクエストを投げる必要がある どのデータが必要なのかは投げられたクエリから判断するので無駄なデータを返す必要がなくなる
RejectKaigi 2017で「GraphQL on Rails」という発表をしました - Bit Journey's Tech Blog
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アーキテクチャという位
graphql-ruby + Railsで簡易なクエリとミューテーションが使えるGraphQL APIを実装する - kymmt
会社でGraphQLのハンズオンがあったのをきっかけに、最近はGraphQLのサーバ側実装をちょっと触っています。 graphql-rubyを使うと、RubyでGraphQL APIを実装することができます。今回はRailsでGraphQLのクエリとミューテーションを実装してみました。 graphql-ruby使用時のRailsプロジェクトにおけるファイル／ディレクトリ構成 rails generate graphql:install すると、ジェネレータが app 配下に次のようなディレクトリ構成を作ります。 app/controllers └── graphql_controller.rb app/graphql ├── app_schema.rb ├── mutations └── types ├── mutation_type.rb └── query_type.rb また、ジェネ
サービス開発を加速させる技術選定 in Kibela - Bit Journey's Tech Blog
2017/07/18 Service Dev Meetup #1 の資料です。 会場は Speee さんに提供していただきました。ありがとうございました。 自己紹介 FUJI Goro / @__gfx__ ビットジャーニーのエンジニア 最近のスコープ: Ruby on Rails / TypeScript / React / GraphQL 情報共有サービス Kibela を開発してます 最近の発表: RailsエンジニアがReactを始めてSSRとReduxとTypeScriptを導入するまで 今日の話 Kibelaにおける技術選定とは やらないこと やったこと これからやること Kibelaにおける技術選定とは 自分（@gfx）にとっては技術的挑戦は精神衛生上必要なこと 興味のある分野に限るが… スタートアップにとってはサービスの成長が最も重要 技術的挑戦によって機能を磨いて差別化に
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
REST API に疲れたあなたへ贈る GraphQL 入門
JS - Blog - GraphQL Best Practices