GraphQLとPersisted Query - Qiita
最近、GraphQL APIをインターネット上に晒す上で何を考慮したらいいのだろうか、的なことを考える機会が多く、空いた時間でチマチマと素振りしています。 今日はGraphQLのクライアント - サーバー間に挟むリバプロ的な機能について書いてみようと思います。 やりたいこと 1. 想定しないクエリの排除 例えばECやメディアサイトのような、未ログインでも情報の閲覧が可能なサービスのWeb API層をGrahpQLで実装したとします。ECにしろメディアにしろ、詳細ページでの回遊率を上げるため、詳細同士を関連付けるようなスキーマ設計となるのは自然なことでしょう。 GrahpQLのスキーマ定義で書くと、下記のようなイメージです。
コードで見る graphql-java 関連ライブラリの関係性 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? graphql-java を Spring Boot などで使う場合、簡単に使えるようにする場合 graphql-java 以外にも色々なライブラリを読み込む必要があります。 これは graphql-java はプリミティブな API しか持っておらず、web 側との繋ぎとか、subscription の対応をそれ単体ではできないためです。 この辺りの関係性が自分の中でも結構曖昧だったり、ドキュメントの情報しか読んでなかったので、コードリーディングしてわかったことをこの記事にメモします。 前提 Spring Boot + Kotlin
Principled GraphQL
Learn how to apply these ten principles with the Apollo Graph PlatformGet Started GraphQL, despite the name, isn't simply a query language. It's a comprehensive solution to the problem of connecting modern apps to services in the cloud. As such, it forms the basis for a new and important layer in the modern application development stack: the graph. This new layer brings all of a company's app data
DAppsのバックエンドにGraphQL + MongoDBによるAPIサーバーを導入すべき理由 - Qiita
DAppsは日本語で、非中央集権型アプリや分散型アプリなどと呼ばれていますが、実際のアプリケーションは全く非中央集権型（Decentralized）ではなく中央集権型（Centralized）のアプリケーション「CApps」になっているというは周知の事実だと思います。 実際問題アプリケーションの楽しさやユーザビリティを考えると、ある程度は中央集権型になるのは仕方のないことなのだと思います。 ではDAppsのユーザービリティの向上を目指すにあたり、どのようなアーキテクチャにするべきなの考えてみます。 キーとなるのは、GraphQL + MongoDBによるAPIサーバーです。 なぜAPIサーバー？ コントラクトの不得意なことの一つとして、一覧データの取得があります。 コントラクト内の一覧データを取ってくるには、データの件数だけループしてトランザクションを発行する必要があったり、コントラクト内
設定いらずのNode製GraphQLサーバー「Graphpack」の使い方 / Query, Mutation, Subscriptionを試す | Takumon Blog
設定いらずのNode製GraphQLサーバー「Graphpack」の使い方 / Query, Mutation, Subscriptionを試す なにこれ 「とりあえずクライアント側と同じJavaScriptで手っ取り早くGraphQLサーバー立てたい！」 このようなユースケースにGraphpackはピッタリです。 設定いらずのNode製GraphQLサーバーで 「GraphQLのスキーマとリゾルバーを定義するだけでOK」、さらに **「GraphQL Playground IDEが標準搭載」**なのでクライアント側を自前で実装せずとも動作確認できます。 今回は、このGraphpackの使い方について以下の5ステップでご紹介します。 ※ここで紹介するソースコードはGitHub(Takumon/nuxt-graphpack-sample)にもあるので参考にしてみてください。 🔰 Graph
Data Types
The data type of a schema is defined by the type keyword, for example, type: string. OpenAPI defines the following basic types: string (this includes dates and files) number integer boolean array object These types exist in most programming languages, though they may go by different names. Using these types, you can describe any data structures. Note that there is no null type; instead, the nullab
GAE GoとDatastoreでGraphQL APIを開発する - Qiita
Google Cloud Platformのマネージドサービスを使ってGraphQL APIを開発してみました。GraphQLについては初心者でしたので、実装しながらGraphQLについて学んだことを記録します。 利用した技術 App Engine SE Go 1.11 Go 1.11が11月にβリリース 2nd genと呼ばれる次世代ランタイム Cloud Datastore スケーラビリティの高いNoSQLデータベース Stackdriver Stackdriver Trace for Goを使いたかったため使用 個人で使う分には無料でいけます。動作も速い！！ GAEの2nd genではプラットフォームのことはあまり意識することなく普通にサーバーを実装すればよいです。 にもかかわらず、必要な時、必要な分だけ高速に起動するので最高です。 主なライブラリ 使用した主なライブラリは以下のとお
AWS Amplify + Vue.js + AppSync + Cognito +その他諸々でリアルタイム更新なサーバレスWebアプリをデプロイ - Qiita
昨年までのAWS Amplify 昨年のServerless Advent CalendarにてAWS AmplifyでサーバレスWebアプリの構築という投稿を書きました。 この投稿では、AWS AmplifyというJavaScriptライブラリを使用して、Cognitoで認証を行い、API Gatewayに対してリクエストを行うというものでした。 従来のREST APIを使用したWebアプリであれば、この仕組みをベースとして構築することで、大抵のWebアプリは構築可能かと思います。 AppSync登場！ 昨年のre:Invent 2017にて発表され、今年の4月にGAとなったGraphQLを使用したフルマネージドサービスであるAWS AppSyncが登場しました。 GraphQLとはや、AppSyncとはは、既に多くの記事で説明があるので、ここでは触れません。 このAppSyncが登場し
AppSync というか GraphQL 設計 Tips 5選
meguro.dev #5の資料です https://meguro-dev.connpass.com/event/110965/
Introspected REST: An alternative to REST and GraphQL | Introspected REST
Skip to the content. Introspected REST: An alternative to REST and GraphQL In this manifesto, we will give a specific definition of what REST is, according to Roy, and see the majority of APIs and API specs (JSONAPI, HAL etc) fail to follow this model. We will see what problems a RESTful API brings and why API designers have been constantly avoiding using it but instead come up with half-way solut
React + Apollo Client (GraphQL) により変化するアプリケーション設計
Node 学園祭2018のトークで使用したスライドです。 https://nodefest.jp/2018/schedule.html#conference-5-8
Reactベース静的サイトジェネレータGatsbyの真の力をお見せします - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? NTTテクノクロスの上原です。 業務では、社内情報のReact製自前キュレーションサイトの構築を担当しています。 この記事はNTTテクノクロスAdvent Calendar24日目の記事であり、社内の勉強会で発表した内容をQiita記事として書きなおしたものです。タイトルは釣りです。 (2018/12/28追記あり) 導入 記事を書いた理由 Gatsby.js(以降、Gatsbyと表記)はさまざまな高速化テクニックを用いた「爆速サイト生成」で有名なツールですが、そのリッチな機能性は、たとえばイントラ内サイト、業務システム開発、ツール開発
2万人に聞いた、2018年の最新JavaScript事情 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 先日よりThe State of JavaScript 2018というアンケートが行われていたのですが、その集計結果が公開されたのでざっくりと紹介してみます。 回答者数は2万人超としか書かれてなくて正確な数は不明です。 というか全体的に大まかな集計結果しか出てなくて、もっと詳しいデータが欲しければ直接連絡しろという方針らしいです。 ちょっと残念。 The State of JavaScript 2018 Introduction 2万人以上のJavaScript開発者が回答したよ。 結果の概要はMediumに投稿してるよ。 色々なプロジ
GraphQL Summit 2018 に参加してきました - Mercari Engineering Blog
フロントエンドエンジニアの @vwxyutarooo (Yutaro) です。11月の7-8日に San Francisco にて行われた GrahpQL Summit 2018 に参加してきましたのでその様子をお伝えします。 フロントエンドからは私とチームメイトの @carlos の2名、バックエンドからも3名参加しました。 現在のメルカリ Web では GraphQL は使われていませんが、アーキテクチャを刷新する Re-Architecture というプロジェクトにおいて GraphQL を使用しています。 トークの内容は YouTube にて公開される予定ですので、全体の雰囲気と私が気になったトークをいくつか紹介します。 GraphQL Summit とは GraphQL Summit 2018 GraphQL Summit は2016年から始まり今年で3年目となります。Graph
graphql-goでブログAPIを作った話 #golang - Qiita
curl -X POST \ https://{url}/v1/contents \ -H 'Authorization: Bearer {とーくん}' \ -H 'Content-Type: application/json' \ -d '{ "title" : "ブログのタイトルをどうしようかなと思っている", "tags": [ "go" ], "body":"#たいとるが決まりません" }' 訳ありのため, mutationでコンテンツ作成は諦めました。 構成 インフラ GAE/Go111 Datastore GAE Second generation(Go1.11) を使用しました。 これにより、appengineパッケージから解放されました。 datastoreも google.golang.org/appengine/datastore ではなく cloud.google.c
ongoing by Tim Bray · Post-REST
More or less all the big APIs are RESTful these days. Yeah, you can quibble about what “REST” means (and I will, a bit) but the assertion is broadly true. Is it going to stay that way forever? Seems unlikely. So, what’s next? What we talk about when we talk about “REST” · These days, it’s used colloquially to mean any API that is HTTP-based. In fact, the vast majority of them offer CRUD operations
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - tylerthebuildor/graphqless: REST and GraphQL really aren't that different. I'll prove it!
GraphQL入門
GitHub - Arkweid/graphql-smart_select: Plugin for graphql-ruby which helps to select only the required fields from the database.
GraphQL Ruby(class-based API)の導入でハマったこと - Qiita
