銀座Rails#40
![GraphQL Highway](https://cdn-ak-scissors.b.st-hatena.com/image/square/eb975b97ea2915194ccf739efed9703515313c37/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F340008e80eb84a2b959aaf2862f66dfd%2Fslide_0.jpg%3F19834818)
この記事は GraphQL Advent Calendar 2019 の22日目の記事です。 qiita.com こんにちは。 vivit株式会社というアウトドア関係のサービスを提供している会社で主にフロントエンドを担当している中村です。 本記事では、fly.ioでGraphQLのキャッシュサーバを立てて高速化した話をします。 はじめに 弊社では、Go + React(TypeScript)で開発しておりAPIにはGraphQLを採用しています。 今回は下記の理由でGraphQLのQuery結果をキャッシュするサーバを実装してみました。 社内向け管理画面で呼び出しているQueryの応答時間が5秒ほどかかっているものがあり、開発時、オペレーション時にストレスが発生している。 技術的な興味 本記事では、 GraphQLをどのようにキャッシュするのか fly.ioでGraphQLのキャッシュサー
scalar型を新しく定義するためにはscalarキーワードを使います。例えば、Date型を新しく定義するには次のようにします。 scalar Date スキーマではこれだけですが、実際に使う際はGraphQL処理系に対してさらにシリアライズとデシリアライズを定義することになります。 GraphQL組み込みのscalar型は先にあげたものだけなので、例えばバイナリ、日付と時刻、HTML/XML、BigIntなどを必要に応じて追加することになるでしょう。ただしその場合、サーバーサイドとクライアントサイドでシリアライズ・デシリアライズの実装を一致させる必要があります。 Enum enum(イナム)はscalar型の一種で、特定の値のみを持つ型です。例えば、組み込みscalar型であるBooleanをenumで宣言すると次のようになるでしょう。 enum Boolean { true false
MF KESSAIでバックエンドのエンジニアをやっている@garsueです。 先日、社内向けサービスの新規開発でGraphQLを採用することになりました。 今回はその経緯や実装方法についていくつか参考記事を交えながら紹介していきます。 なぜGraphQLか 今回新規で開発するサービスは以下のような特徴があります。 MF KESSAIの内部は複数のサービスに分かれていて、それらをふんだんに利用する 社内向けなので直近でそこまで高負荷になる見込みはない フロントエンドとバックエンドのすり合わせにあまり時間をかけたくない(そんなに時間はない) まず複数サービスとの協調という点について、マイクロサービスをベースとしたGraphQLとGoによる開発を紹介した記事Using GraphQL with Microservices in Goにある内容をそのまま適用できそうだなというところからGraphQ
この記事は GraphQL Advent Calendar 2018 の22日目です。 どうも、HiCustomerのエンジニアの@m4s4k3xです。 GraphQLが広く使われるようになって久しいですが、弊社でも、以下の理由などからGraphQLを導入することにしました。 BFFを立てるほどのエンジニアリソースを割かなくてよい Union TypesやEnumと言ったスキーマの型表現が可能である エコシステムが豊富 大量のエンドポイントを増やさなくても良い 一度のリクエストでフロントエンドで必要なリソースが取得可能 Goにおいての採用事例もちらほら見かけるようになりました。GoにおけるサーバーサイドにおけるGraphQLライブラリはメジャーなものが5つほどあります。各々のライブラリの横断的に紹介した後、弊社での選定理由を紹介します。 GoにてGraphQLの導入を検討している方への助け
この記事はJX通信社Advent Calendar&GraphQL Advent Calendarの1日目です。 JX通信社でNewsDigestというアプリを開発しているyamitzkyです。 NewsDigest では、アプリから利用する API に GraphQL を利用 しています。本番での利用を始めてからちょうど1年を過ぎました。 JX 通信社ではプログラミング言語として Python が使われることが多く、この GraphQL API も Python で作ってサーバーレス環境(AWS Lambda)にデプロイ していました。しかし、Lambda では要件が合わなくなってしまったため、現在では Amazon ECS で作った Docker クラスタ内で動いています。また、非サーバーレス化に合わせて、パフォーマンス要件を満たすために Go でのリプレイスを行いました。 この マイ
「参照系はGraphQLだけど、更新系はRESTでPOSTにします」みたいな意見を稀によく見る。 もちろん何かしらのトレードオフを考えてRESTを選択しているのだとは思うのだけど、GraphQLのmutation(要は更新系)を誤解している人も中にはいるのではなかろうか。 先日GraphQLのmutationは難しそう……という意見をもらって、詳しく聞いてみるとmutationについて誤解があるようだった。 もしかしたら同じような勘違いをされている方は他にもいるかもしれないなーと思ったのでまとめておく。 あーそれは多分誤解があるような気がしますね!mutationの方は投げるクエリを変えることで、動的に更新対象を変化させる……みたいなことは志向していないと思います。 ここの例のsetMessageをみてもらうと分かりやすいかと!https://t.co/Jq08v5n4x6— すーさん二号
mercari.go #2 登壇資料です https://mercari.connpass.com/event/95665/
2018年4月21日、株式会社サイバーエージェントが主催するイベント「Battle Conference U30」が開催されました。30歳以下のエンジニアによる30歳以下のエンジニアのための技術カンファレンスである本イベントには、さまざまな領域で活躍する若手が登壇。企業の枠を超えて、自身の技術・事業・キャリアに関する知見を発表しました。「Nuxt.jsとGraphQLから見えたWeb開発の未来」に登壇したのは、株式会社スマートドライブの大木尊紀氏。Nuxt.jsとGraphQLを開発に用いるメリットと、今後のフロントエンドエンジニアの価値について語りました。 Nuxt.jsとGraphQLに見る、Web開発の未来 大木尊紀氏(以下、大木):よろしくお願いします。「Nuxt.jsとGraphQLから見えたWeb開発の未来」とけっこう大層なこと言ってますけど、最後までお聞きください。 大木尊紀
今年GitHubがGraphQL APIを正式公開したあたりから、GraphQLが去年とかに比べちょっと流行り始めたように感じる。idobataがGraphQL APIを公開したり、Kibelaも公開APIをGraphQLで作ることを宣言している。 利用者側からすると使えるインターフェースの中から必要なものを調べて使うだけなのであまり考えることはないのだが、自分がAPIを提供する立場になると話は変わってくる。REST APIとGraphQL APIはどちらかがもう一方のスーパーセットという風にはなっておらず、どちらかを選択すると何かを捨てることになるので、要件に応じてどちらを選ぶのが総合的に幸せなのか考える必要がある。 以前趣味でGitHub連携のあるサービスを作っており、それを最近GraphQL API v4を使うように移行し、そこでついでにそのサービスのGraphQL APIを書いてみ
このあいだ GitHub が公開していた GraphQL API が便利そうだったので使おうと思ったのだけど、求めたライブラリがなかったので作った次第です。 ここで GraphQL についての説明はしませんが、結果の JSON とクエリが同じ形を持っているのが便利で美しいですね。ということは API の結果の JSON を受け取る struct から GraphQL のクエリが生成できるのが自然でしょう。そういうことをやってくれるシンプルなライブラリです。 GitHub - motemen/go-graphql-query API シンプルな例 ディレクティブとエイリアス 引数と変数 インラインフラグメント 複雑な例 軽い気持ちで書きはじめたところ GraphQL に予想外の表現力があることがわかったのでけっこう無理をしているところもあります。一般的にどんな使い方がなされるのかわかってない
自分でGraphQLサーバーを実装しながら勉強したログ。間違ってるかも。 コードはここにあるが、何の注釈もない。 https://github.com/mizchi-sandbox/play-graphql-server RESTの課題 REST は URI とモデルのマッピング構造だが、往々にしてクライアントで必要となる構造は モデルのうち一部であったり、そのリレーショナルな構造に依存する。 つまり、REST というルールに従って必要なデータを組み立てると、リレーショナルな構造によってN回のリソースへのアクセスと、興味がないデータを含んだ不要なペイロードが発生しがちである。 GraphQL は何をしたいか 1リクエスト内でモデルへの問い合わせを合成し、さらに必要なものだけ返却したい 言語とは独立した、転送経路上のモデルの定義を行いたい パフォーマンス上の理由とセマンティクスが同居している
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く