こんにちは!LayerXの mosa_siru (榎本) です。 LayerX インボイスでは、もともと github.com/go-swagger/go-swagger を利用してREST APIを開発していましたが、最近開発したワークフロー機能 のコンポーネントではGraphQLを取り入れました。 GraphQLには様々なメリットがあり、RESTとの比較記事は多くありますが、なぜ僕らは移行したのか、その結果どうなったのかを紹介していきます。 GraphQLのメリット GraphQLのメリットは、様々な箇所で語られています。例えばこの記事によれば、 強力に型付けされたスキーマであること アンダーフェッチとオーバーフェッチがないこと(後述) Apollo, Relayなどの、クライアントライブラリにより、フロントエンド開発が迅速になること 複数のGraphQL APIからの統合が可能 強力
今年GitHubがGraphQL APIを正式公開したあたりから、GraphQLが去年とかに比べちょっと流行り始めたように感じる。idobataがGraphQL APIを公開したり、Kibelaも公開APIをGraphQLで作ることを宣言している。 利用者側からすると使えるインターフェースの中から必要なものを調べて使うだけなのであまり考えることはないのだが、自分がAPIを提供する立場になると話は変わってくる。REST APIとGraphQL APIはどちらかがもう一方のスーパーセットという風にはなっておらず、どちらかを選択すると何かを捨てることになるので、要件に応じてどちらを選ぶのが総合的に幸せなのか考える必要がある。 以前趣味でGitHub連携のあるサービスを作っており、それを最近GraphQL API v4を使うように移行し、そこでついでにそのサービスのGraphQL APIを書いてみ
最近、GraphQL APIをインターネット上に晒す上で何を考慮したらいいのだろうか、的なことを考える機会が多く、空いた時間でチマチマと素振りしています。 今日はGraphQLのクライアント - サーバー間に挟むリバプロ的な機能について書いてみようと思います。 やりたいこと 1. 想定しないクエリの排除 例えばECやメディアサイトのような、未ログインでも情報の閲覧が可能なサービスのWeb API層をGrahpQLで実装したとします。ECにしろメディアにしろ、詳細ページでの回遊率を上げるため、詳細同士を関連付けるようなスキーマ設計となるのは自然なことでしょう。 GrahpQLのスキーマ定義で書くと、下記のようなイメージです。 type Product { id: ID! name: String! relatedProducts: [Product] } type Query { produ
graphql-java を Spring Boot などで使う場合、簡単に使えるようにする場合 graphql-java 以外にも色々なライブラリを読み込む必要があります。 これは graphql-java はプリミティブな API しか持っておらず、web 側との繋ぎとか、subscription の対応をそれ単体ではできないためです。 この辺りの関係性が自分の中でも結構曖昧だったり、ドキュメントの情報しか読んでなかったので、コードリーディングしてわかったことをこの記事にメモします。 前提 Spring Boot + Kotlin で graphql-java-tools を使う場合で考えます。この辺りについては会社のブログの方でも書いたので、こちらもよければご参考にしてください。 以下のライブラリを使います。 graphql-java https://github.com/graph
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は日本語で、非中央集権型アプリや分散型アプリなどと呼ばれていますが、実際のアプリケーションは全く非中央集権型(Decentralized)ではなく中央集権型(Centralized)のアプリケーション「CApps」になっているというは周知の事実だと思います。 実際問題アプリケーションの楽しさやユーザビリティを考えると、ある程度は中央集権型になるのは仕方のないことなのだと思います。 ではDAppsのユーザービリティの向上を目指すにあたり、どのようなアーキテクチャにするべきなの考えてみます。 キーとなるのは、GraphQL + MongoDBによるAPIサーバーです。 なぜAPIサーバー? コントラクトの不得意なことの一つとして、一覧データの取得があります。 コントラクト内の一覧データを取ってくるには、データの件数だけループしてトランザクションを発行する必要があったり、コントラクト内
設定いらずのNode製GraphQLサーバー「Graphpack」の使い方 / Query, Mutation, Subscriptionを試す なにこれ 「とりあえずクライアント側と同じJavaScriptで手っ取り早くGraphQLサーバー立てたい!」 このようなユースケースにGraphpackはピッタリです。 設定いらずのNode製GraphQLサーバーで 「GraphQLのスキーマとリゾルバーを定義するだけでOK」、さらに **「GraphQL Playground IDEが標準搭載」**なのでクライアント側を自前で実装せずとも動作確認できます。 今回は、このGraphpackの使い方について以下の5ステップでご紹介します。 ※ここで紹介するソースコードはGitHub(Takumon/nuxt-graphpack-sample)にもあるので参考にしてみてください。 🔰 Graph
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アプリをデプロイAWSVue.jsserverlessaws-amplifyAppSync 昨年までのAWS Amplify 昨年のServerless Advent CalendarにてAWS AmplifyでサーバレスWebアプリの構築という投稿を書きました。 この投稿では、AWS AmplifyというJavaScriptライブラリを使用して、Cognitoで認証を行い、API Gatewayに対してリクエストを行うというものでした。 従来のREST APIを使用したWebアプリであれば、この仕組みをベースとして構築することで、大抵のWebアプリは構築可能かと思います。 AppSync登場! 昨年のre:Invent 2017にて発表され、今年の4月にGAと
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
NTTテクノクロスの上原です。 業務では、社内情報のReact製自前キュレーションサイトの構築を担当しています。 この記事はNTTテクノクロスAdvent Calendar24日目の記事であり、社内の勉強会で発表した内容をQiita記事として書きなおしたものです。タイトルは釣りです。 (2018/12/28追記あり) 導入 記事を書いた理由 Gatsby.js(以降、Gatsbyと表記)はさまざまな高速化テクニックを用いた「爆速サイト生成」で有名なツールですが、そのリッチな機能性は、たとえばイントラ内サイト、業務システム開発、ツール開発などでも十分に活用できるものだと思い、その可能性を紹介するために書きました。 「静的サイトジェネレータ」って何? いわゆる「静的サイトジェネレータ(Static Site Generator, SSG)」は、CMS(コンテンツ管理システム)の一種です。代表的
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く