20230830_ArchitectGroup_SWTT再演(GraphQL)
•Download as PPTX, PDF•
0 likes•201 views
2023/7/21に開催された「World Tour Tokyo」において行ったセッションの再演です。 (2023/8/30の再演に際し、Winter'24リリース関連を追記)
Recommended
Recommended
More Related Content
Similar to 20230830_ArchitectGroup_SWTT再演(GraphQL)
Similar to 20230830_ArchitectGroup_SWTT再演(GraphQL) (20)
More from Takashi Hatamoto
20230830_ArchitectGroup_SWTT再演(GraphQL)
- 3. 畑本 貴史 / Takashi Hatamoto 株式会社チームスピリット サービスディベロプメントディビジョン TSFエンジニアリングチーム エキスパート • Salesforceエンジニア歴13年 • 現職では5年近くAppExchange開発 • Salesforce Developer Group Tokyo 運営メンバー • Salesforce Saturday Japan (京橋) 主催 • 元Lightning App Dev Champion • 学生時代は空を飛んでいたらしい・・
- 4. 社内ではこのようなプロダクトを開発しています • TeamSpirit • 勤怠管理、工数管理 • 経費申請、電子稟議 • シフト管理、入退館記録連携 • TeamSpirit Leaders • プロジェクト原価管理（TS工数実績と連携） • TeamSpirit HRM • 社員情報管理（TS社員情報と連携） • 諸届ナビ（申請ウィザード作成） • TeamSpirit マイナンバーエンジン • マイナンバー登録（TS/HRMと連携）
- 6. Winter’23で、新しいSalesforce API「Graph QL」がリリースされた • Summer’22：ベータ版公開 • Winter’23 ：正式リリース • Spring ’23：クエリの機能追加 • 位置情報に基づくクエリを実行する • 相対日付でクエリを絞り込む • 関連リストメタデータを取得する • Summer’23：クエリ強化、およびSalesforce Connectで利用可 • GraphQL の新しい Salesforce Connect アダプタで外部ソースからのデータにアクセス • 集計関数を使用してレコードを照会する • グルーピングで集計関数を使用する • 要求からエラー情報を取得する • PicklistOperators 検索条件種別でより多くの比較演算子を使用する
- 7. 追記：Winter’24で更に更新が！！ • GraphQL APIがミューテーション（DML）に対応 • ページネーション時に件数上限を設定 • パッケージ名前空間に対応 • 集計関数の結果を並び替えに利 • 活動オブジェクトに対応 • 複合項目(住所)に対応 • 数値項目のdisplayValueの仕様変更 • LWCのGraphQL ワイヤーアダプターが正式リリースされた
- 8. 例えば、GraphQLでこういうことができます • 1回のクエリ実行で、複数オブジェクトのデータを一括取得できる 同じネストの中で複数の要素を書けるので、SOQL複数回分のクエリを実行できる • オブジェクトの項目定義をクエリで取得できる オブジェクト定義取得(Sobject Describe)相当の機能もクエリとして実行できる （これも複数同時に！） • 検索結果の取得条件を柔軟に制御できる • 検索条件・取得件数・ソート順等の設定をバインド変数に格納できる • 選択リストの値に対して不等号・LIKEで比較できる
- 9. そもそも、GraphQLとは？ →REST APIの欠点を補う、新しいAPIとそこで使うクエリ言語 「グラフ構造」に沿ってアクセス先を記述する 沿革 • 2012年 facebook(現：META)により開発 • 2015年に仕様公開 • 現在はGraphQL Foundationに管理を移管
- 11. 一般的な（自由度のない）REST APIを使った場合のデメリット • 必要なデータが集まるまで複数のコールを繰り返すことになる • 多数のコールをかけることでサーバー負荷を上げてしまう • フロントエンドでデータを成型する必要が生じる →GraphQLを使えば、1回のクエリ実行で必要十分なデータが取得できる • 狙ったデータが1回で取得できるため何度もコールしない • コール数を節約できるのでサーバー負荷がかからない • データがクエリで定義した形式に変換されているためそのまま使える →フロントエンド開発を円滑化できる
- 12. Salesforce開発者にとってのメリットはあるか？ • SalesforceのREST APIはかなり自由が利く • sObject APIによる任意のオブジェクトに対する柔軟なコール • UI APIによる標準のアクセス設定に準拠した安全なコール • SOQL/SOSLによるクエリを使った自由なデータ取得 • Apex Webサービスを使って高度なデータ変換ができるAPIを自作できる • Apexを使えば高機能なサーバサイド処理を実装できる • Apex WebサービスでREST APIと同様にコールできるAPIを開発できる
- 13. Salesforceの既存APIに対するGraphQLのメリット 1. 標準REST APIに対して • 複数のオブジェクトに対するコールを1回で実行できる • 複数種類のAPIコールと同じ内容を同時に実行できる →APIコール数を節約できる 2. Apex (画面コンローラ、Webサービス)に対して • 今までApex開発が必要だった処理をGraphQLだけで実装できる • LWCからワイヤーサービスとして呼び出せる→LDSと連携できる →サーバーサイドの開発工数を減らせる →最適な実装方法の選択肢が増える
- 14. Salesforce開発における利用箇所 1. 外部システム→Salesforceへのコールアウト • REST API経由でGraphQLクエリをコールできる • オブジェクトのレコードデータ・メタデータを併せて取得可能 2. Salesforce内部の画面→バックエンドへのアクセス • 現状は外部システムと同様にREST APIでコールする • LWC向けのWireアダプタが開発中(Winter’24でGA！！！)
- 16. GraphQLの実行方法 →既存のREST APIと基本的に同じ！(REST APIの一種) • Altair GraphQL Client 1. 接続アプリケーションの認証情報を用意する 2. OAuth2.0認証フローを実行し、アクセストークンを取得する 3. 認証ヘッダーにアクセストークンを設定する 4. リクエストボディにGraphQLクエリを記述し、コールアウトする エンドポイントURL https://[エンドポイントのドメイン]/services/data/v[実行バージョン番号]/graphql
- 17. おすすめのクライアント 1. Altair GraphQL Client https://altairgraphql.dev/ • PC版とブラウザ拡張版 • GraphQL専用クライアント • 組織のスキーマ情報を簡単に 一括取得できる • API実行前後のスクリプトも 実行できる
- 18. おすすめのクライアント 2. Postman https://www.postman.com/ • PC版とWebページ版 • GraphQL以外にも様々な APIを網羅する汎用クライ アント • SalesforceとのOAuth認証→ トークン保存機能もあり
- 19. その他の実行方法 • Lightnig Web Component向け 「GraphQL Wire アダプタ」が開発中 （Summer’23時点でベータ版） • lwc-recipesにもGraphQLサンプルが掲 載される https://developer.salesforce.com/docs/c omponent- library/documentation/en/lwc/lwc.refere nce_lightning_graphql_api
- 25. GraphQLについてのまとめ • GraphQLは、他システムのAPIと互換性のある新しいクエリ言語である • GraphQL APIは、既存のAPIの複数機能を内包した新しいAPIである • GraphQL APIの拡張が進むことで、SalesforceのAPI機能でできることが増える • GraphQL APIと既存のAPIを使い分けることで、新規機能開発を効率化できる GraphQL APIガイド・リファレンス： https://developer.salesforce.com/docs/platform/graphql
Editor's Notes
- 皆さんこんにちは。本日は 「GraphQLってなんだ？」というタイトルで、ご存じの方もそうでない方にも概要を一通りご理解いただけるようご説明いたします。
- はじめに自己紹介をさせてください。
- わたくしTeamSpiritの畑本と申します。皆さんからは「親方」と呼ばれることが多いです(笑) Salesforce開発は10年以上やっておりまして、以前はインプリ業務をおこなっていましたが、 現在はチームスピリットでAppExchange製品の開発に携わっております。 また幾つかコミュニティ活動にも関わっております。
- ちなみに、会社ではこのようなプロダクトを開発しています。 今回の発表は業務と直接関係ないので多くは申し上げませんが、ご興味ある方はぜひお声かけください(笑)
- では本題として、GraphQLについて説明させていただきます。
- Winter’23から、新しいAPIが実装されたことはご存じでしょうか？実のところ私もノーマークでしたが、 数えてみますとこのようにリリース後もコツコツと機能追加され続けています。しかも外部接続コネクタにも採用されているみたいなんです。 ちょっと気になって調べてみました。
- Winter’23から、新しいAPIが実装されたことはご存じでしょうか？実のところ私もノーマークでしたが、 数えてみますとこのようにリリース後もコツコツと機能追加され続けています。しかも外部接続コネクタにも採用されているみたいなんです。 ちょっと気になって調べてみました。
- 具体的には、GraphQLでこのようなことができるみたいです。 例えば、1回のクエリで複数のオブジェクトを一括取得できます。GraphQLは同じネストに複数の要素を書いて実行でき、結果も同時に返すことができます。 また、オブジェクトのデータのみならず、オブジェクト定義情報も返すことができます。いわゆるメタデータは本来別のAPIから取得するものでしたが、GraphQLではクエリで取得できます。 文法面でも特徴があります。検索条件やソート条件を本文と別の変数にバインドできたりします。ちょっと面白いのが選択リスト値に対する比較が充実しているところです。これはSOQLではありえなかったことです。
- そもそもの話をしますと、実はGraphQLはSalesforceの発明ではございません。 最初に開発したのはfacebookです。仕様公開されたのは2015年で、 現在はGraphQL Foundationという独立組織に管理移管しています。 つまり特定のサービス向けではないオープンな規格なんです。GraphQLを主体としたAPIを使って運用しているサービスも多いようです。
- ではなぜGraphQLが採用されるのか、具体的なメリットを説明します。
- まずGraphQLを使わず、一般的なREST APIを使った場合のデメリットについてです。 一般的なREST APIはそれぞれ特定の要件に沿って定義されているため、新しい要件には最適化されていません。 そのため開発者は必要なデータを取得するために複数のAPIを組み合わせることになります。 これによってコール数が増えサーバー負荷が上がる、データ成型の必要が生じることもあります。 しかしGraphQLを使えば、必要なデータはクエリで定義したとおりに取得できます。 要件に合わないコールを繰り返すことはなく、データも整形済みです。つまりフロントエンド開発の手間がなくなり、円滑になるんです。
- ではSalesforce開発においてGraphQLは有益なAPIと言えるのでしょうか？ 実のところ、SalesforceのAPIはかなり充実しています。 標準のREST APIにしても、システム全般を自由に操作できる強力なAPIや標準アクセス設定に準拠したAPI、 クエリを使ったデータアクセスも既にあります。 更にApexを使えば、より高機能で要件に最適化されたAPIを自作することもできます。
- 標準REST APIに対しての優位性として、GraphQLが複数のオブジェクト、複数の機能に関するコールを まとめて実行できる点が挙げられます。 既存のREST APIでは各オブジェクトに対して、機能別に1回ずつAPIをコールしていたのが、1回で済むようになります。 これはAPIコール数の節約になります。 Apexに対する優位性として、今までApexでしか実現できなかったデータ変換処理をクエリ、つまりローコードとして実行できる点が挙げられます。 Apex開発者によるサーバーサイド開発を減らすことができます。 全ての手段にそれぞれメリットとデメリットがある上で、それを理解し使い分けることが重要です。
- 現状、GraphQL APIはREST APIの一種としてコールすることになります。 主にSalesforceのデータを取得する際に、GraphQLクエリをコールしてデータを検索します。 なのでSalesforce内の画面からもAPIアクセスをしなければなりません。 これを解消するため、LWCからwireサービスでGraphQLをコールできるアダプタを開発中です。
- では残りの時間で、実際にGraphQLをお試し頂く手順をご紹介します。
- GraphQLの実行方法は、実は既存のREST APIと原則同じです。 REST APIの一種と言って差し支えないです。 実行に必要なパラメータは接続組織のGraphQL本文のほかにドメイン、実行APIバージョン、そしてセッションIDを含むアクセストークンです。
- GraphQL APIをお試し実行するおすすめのクライアントを2つ紹介します。 一つはアルテアGraphQLクライアントです。GraphQL専用クライアントとして高い実績があります。 組織のスキーマを簡単に取得でき自由に閲覧できるので、文法やオブジェクト定義を調べながらクエリを設計できます。
- もう一つはPostmanです。こちらはSaleforceに限らず様々なREST APIを網羅した万能クライアントです。 Salesforce関連のAPI設定も充実しており、OAuth認証も簡単にできます。 GraphQLのサンプル文も幾つかあるのですぐに試すことができます。
- もう一つの手段として、ベータ版として提供されているLWCのWireアダプタを実装する方法があります。 GraphQLリファレンスやLWC-レシピにサンプルコードがありますので、セッション管理が面倒ならこれを含むLWCを 実装してしまう手もあります。
- では幾つかサンプルを見ていきましょう。 まず初めに、AccountとContactの親子関係のデータを取得してみましょう。 SOQLでも簡単に実行できるクエリですが、GraphQLで記述するときはクエリの構文もJSONのようにネストさせます。
- 2つ目はスキーマからオブジェクト定義を取得するクエリです。 既存のREST APIではデータと定義情報ではエンドポイントを使い分けて取得していましたが、 GraphQLではデータ取得と同じエンドポイントで取得できます。
- 最後に、複数の要素を組み合わせたクエリを書いてみます。 このクエリではオブジェクト定義とデータの両方、AccountとContactの両方を記述しています。 このような欲張りなクエリでも、個々の構文が間違っていなければGraphQL API はすべての結果をマージして返してくれます。
- LWC-RecipesにGraphQLサンプルコードが複数追加されていましたので、そちらを応用してワイヤーサービスを試してみました。 これはレコードページに埋め込んだコンポーネントなんですが、標準コンポーネントで行った取引先・取引先責任者の更新が 自動的にこちらのコンポーネントにも反映されていることがわかります。これはApexでワイヤーサービスを使った場合には原則起きない、 GraphQLならではの強みとも言えます。
- では最後にまとめです。
- ・GraphQLは新しいオープンな規格のクエリ言語です。これを採用している他システムとも互換性があります。 ・これをSalesforceに実装したGraphQL APIは、既存のAPIの複数機能を1つで実現した新しいAPIです。 ・GraphQL APIの機能が拡張されることで、開発者がAPIでできることが増えていく期待があります。 ・過去のAPIやApexを使った実装も引き続き可能ですので、最適な手段を使い分けて今後の開発に活かしてください。
- といったところで、本日の発表内容は以上となります。ご清聴ありがとうございました。