Morning Girl

Web API, Windows, C#, .NET, Dynamics 365/CRM etc..

Meetup #8 GraphQL Tokyo 2019 Summer のまとめにもならない参加メモ

はじめて GraphQL関係の勉強会「Meetup #8 GraphQL Tokyo 2019 Summer」に参加してきたました。

f:id:sugimomoto:20190816114035p:plain

www.meetup.com

セッションはオープンスペースという形式で参加者から募集したトピックと投票によって決定します。初めてだったんですが、事前にスライドの準備などはなく、ライブで進んでいくのが新鮮で面白かったですねー。

bliki-ja.github.io

全部で4セッション(2セッション X 前半後半)で、私は「マイクロサービスのサービス間通信で GraphQL を使うのは他の手法と比べてどうかの議論」と「SDL first or code-first ? https://www.prisma.io/blog/the-problems-of-schema-first-graphql-development-x1mn4cb0tyl3」に参加しました。

以下、勉強会が終わったあとに、思い出すままに書いているざっくりしたメモの走り書きです。正直ついていくだけでめちゃくちゃハードだったので、まとまってもいないです。

マイクロサービスのサービス間通信で GraphQL を使うのは他の手法と比べてどうかの議論

@mtsmfm さんの社内での展開も含めた課題感からの議論

現在社内ではgRPCでマイクロサービスを構成している → Why?

・今まではRESTで実装されていたが、API Spec的な仕様の共有方法も無く、つらみが多くなっていた

・gRPCというよりも、ProtocolBufferがほしかった。 → これによって、クライアントサイド・サーバーサイドの実装がスキーマから生成できて、楽になるんじゃない? みたいなところを狙っていた

・でも、gRPCは仕様的にちょっとネックポイントがある → メインがProtocolBufferによるSpecの共有観点ならばGraphAPIもありなんじゃない? というのが今回の話の流れ

なぜgRPCはネック?

  1. HTTP2 → 社内のインフラがHTTP1前提で構成されていたのでgRPCを採択するにあたって、かなり手を加えなければいけない

  2. gRPCリッチすぎ →「Unary」「Server streaming」「Client streaming」「Bidirectional streaming」とあるけど、プロトコルの要件的にそこまで高機能を求めていない。

  3. ProtocolBufferの型ゆるくない? → 特にオプション周りがゆるすぎ感

他のスキーマファーストもどうなのよ?

  1. OpenAPI(Swagger)

  2. JSON Schema

などなど。(RAMLもか)(あまり話にはのぼらなかった)

ProtocolBufferが大事なら、ProtocolBuffer+HTTP1という手もいいんじゃないの?

(なんかツールの名前を話していた気がするが思い出せない)

(でもそれなら、OpenAPI(Swagger)・RAML・JSON Schemaという手もあるよね?)

rejoinerというアプローチもあるよね

gRPCを束ねて、GraphQLのサービスを提供する仕組み

https://github.com/google/rejoiner

API Management系のサービスでもよくあるパターンか。SOAP→RESTへのプロトコル変換 バックエンドのAPIリクエストを束ねるタイプのもの的な)

でも GraphQL の仕様的にマイクロサービスに向かなくない?(結論的な)

GraphQLの思想的にネストされたリソースや複数リソースを効率的に取得する、UIベースのクライアントサイドで処理しやすいような取得を求められるケースが多い。

そもそもRPC的なアプローチが多いと考えると、GraphQLでマイクロサービスを実装した場合、全部Mutationを使うことになりそうじゃない? とか。(私的意見)

マイクロサービスの文脈だと、もっと固定的(?なんて表現したらいいんだろう)な処理が多くなりそうだから、GraphQLの特性を活かしきれないのではないか?

SDL first or code-first ? https://www.prisma.io/blog/the-problems-of-schema-first-graphql-development-x1mn4cb0tyl3 スキーマファーストかコードファーストか

www.prisma.io

Prismaの中の人がスキーマファーストに問題があるよーみたいな話をしているけれど、それって実際どうなのよ? というのを議論したい

そもそも、PrismaはPrisma1でスキーマファーストいいよ! って言っていた立場じゃないの? そこからリゾルバの生成とDBのスキーマ生成もやってなかったっけ?

ただし、ライブラリ・ GraphQL as a Service の人たちのBlogなので、ポジショントーク的なところも意識しながら読む必要あり。

上記Blogでは、以下のスキーマファースト問題点がピックアップされていたので、それをベースに話をしました。

Problem 1: Inconsistencies between schema definition and resolvers

Problem 2: Modularization of GraphQL schemas

・GraphQLは公式の仕様として、ファイルのモジュール化をサポートしていないよね? という話

・でも、Prismaが拡張仕様としてgraphql-importを出して、他のライブラリなどもそれに追従しているのが流れ

・大量のスキーマを一ファイルで管理するのは得策ではない。だから、スキーマファーストは厳しいよね? という話だが→果たして本当にそうなのか? ファイルを分けて、あとでマージするのを内部で行ってもいいんじゃない? とか。

・確かにコードファーストでクラスファイルライクにモジュール分割できれば楽だけど、コードファーストのスキーマ表現力にはまだ各言語ごとの実装に不足がある?とか

・コードファーストにしてしまうと、GraphQLのスキーマから各言語ごとのスキャンフォールディングした実装を生成するのが困難になっちゃうよね、とか

スキーマファーストでカスタムLinterを定義して、そのカスタムLinterも共有できるようにしたいよね(なるほど)

Problem 3: Redundancy in schema definitions (code reuse)

Problem 4: IDE support & developer experience

・そもそもスキーマファイルってIDEで実装する際はプレーンなテキストファイルとしか認識されないよね? →で もVS CodeとかでシンタックスハイライトやLinterが出てるんだから、小さな問題じゃない?

その他トピックとして気になったものメモ

GraphQLでAPIを提供する GraphCMSというものがあるらしい

graphcms.com

Prisma2 について

www.prisma.io

AWS Appsync の話も聞きたかったな

aws.amazon.com

PowerApps Portals で問い合わせページを作る ③ エンティティ・ページアクセス許可の設定

前回の記事では一覧画面を作成しました。

今回はその一覧画面に対して、ログインしたユーザーでアクセス範囲を規定する設定を、ポータルを通じて実現してみたいと思います。

docs.microsoft.com

続きを読む

PowerApps Portals で問い合わせページを作る ② 問い合わせ履歴一覧の構成

前回に引き続き、PowerApps Portals でお問い合わせページを作ります。

今回作るもの

前回は問い合わせフォームを作りましたが、今回はその問い合わせの履歴を表示する一覧画面を作りたいと思います。

こんな感じで過去に投稿した問い合わせが表示されます。また、件名をクリックすることで、詳細画面に移動するようにもしました。

f:id:sugimomoto:20190801232516p:plain

続きを読む

PowerApps Portals で問い合わせページを作る ① フォームの構成

前回の記事では PowerApps Portals の全体的な要素について見渡してみました。

今回から、何回かに分けて、シナリオベースで PowerApps Portalsの「アプリの作り方」をざっくりと見ていきたいと思います。

続きを読む

PowerApps Portals(Preview)ことはじめ。初期構成&関連情報まとめ

個人的待望の PowerApps Portals のプレビューがリリースされましたねー。

powerapps.microsoft.com

Dynamics 365 Portal(遡れば ADX Studio)をベースにしたこの新機能、以前はかなり触っていたので、こっちもちょこちょこ触ってみました。今回は基本的な構成方法と各画面周りをざっくり見渡してみたいと思います。

続きを読む

CallConnect REST API を使って、PowerBI で通話対応分析レポートを作成してみる(CData REST ODBC Driver)

前回の記事で CallConnect REST をざっと触ってみました。

kageura.hatenadiary.jp

今回は、Microsoft PowerBI と を組み合わせて、レポートを作成しています。

Power BI | 対話型のデータ視覚化 BI ツール

CData REST Driver

f:id:sugimomoto:20190729105724p:plain

続きを読む

CallConnect REST APIを触ってみる

久しぶりに機能・API両面で気になるクラウドサービスがあったので、触ってみました。

コールセンターを手軽に始めることができるSaaS型のクラウドサービスである「CallConnect」です。

https://www.callconnect.jp/

f:id:sugimomoto:20190715234521p:plain

この記事ではざっくりとAPI情報周りのまとめと認証方法、HTTPリクエスト(Postman)からのリクエスト方法についてまとめています。

次の記事では、Microsoft PowerBI から接続する方法について投稿する予定。(準備中)

続きを読む