Rails / GraphQLでAPIサーバーを開発して感じた使い勝手.pdf

Transcript

1. Rails × GraphQLでAPIサーバー を開発して感じた使い勝手 created_at: 2019-03-23　updated_at: 2019-03-25
2. @buena926 椎野 太喜 (22) ◇ 趣味 ・旅行 ・釣り ・スノーボード ◇ 免許 ・PADIオープンウォーターダイバーライセンス ・普通自動車免許（AT限定） 茨城県出身 redish株式会社　新卒エンジニア Rails / Angular / Vue / Nuxt / AWS 自己紹介
3. 今日の話ついて 「自分自身のテックブログを作ろう！」がきっ かけ 右のような感じでバックエンドとフロントエンドを 分けて作ってみたい。 GraphQLをRails（APIモード）に導入して開発し たみたお話です。 クライアントアプリ (React) APIサーバー (Rails) GraphQL or REST
4. GraphQLとは？ Facebook社が開発したAPI用のクエリ言語 ・データの取得や更新を基本的にPOSTで行う ・POSTのリクエストパラメーターにクエリを生やして、APIに対して行いたい処 理を指定する RESTfull APIと比較対象にされる技術
5. GraphQLでよかったこと A）APIの設計がとてもシンプル 　① エンドポイントが1つだけ 　② APIのレスポンスについて指定する必要がない B）クライアントの実装が楽になる 　① クエリの実行環境とドキュメントを提供してくれるツールがある 　② 欲しいデータのみをリクエストできる
6. GraphQLでよかったこと A）APIの設計がとてもシンプル 　① エンドポイントが1つだけ 　② APIのレスポンスについて指定する必要がない B）クライアントの実装が楽になる 　① クエリの実行環境とドキュメントを提供してくれるツールがある 　② 欲しいデータのみをリクエストできる
7. ① エンドポイントが1つだけ RESTfull API　 GraphQL　
8. ② レスポンスの詳細について指定する必要がない QueryTypeにAPIで扱うリソースの型を定義しておく（静的型付けよい） あとは、Queryに指定するだけでリクエストに応じた柔軟なレスポンスになる
9. GraphQLでよかったこと A）APIの設計がとてもシンプル 　① エンドポイントが1つだけ 　② APIのレスポンスについて指定する必要がない B）クライアントの実装が楽になる 　① クエリの実行環境 + APIドキュメントツールがある 　② 欲しいデータのみをリクエストできる
10. ① クエリの実行環境 + APIドキュメントツールがある クエリ実行環境 APIドキュメント
11. ② 欲しいデータのみをリクエストできる Request Params JSON Response [GET] https://myblog.com/graphql?query=graphql_query
12. Request Params JSON Response [POST] https://myblog.com/graphql?query=graphql_query ② 欲しいデータのみをリクエストできる
13. Rails × GraphQLのテストについて ① クエリのテストを書く ・クエリ全体のテスト 　⇒ システム全体で「健全性チェック」 ・各クエリのテスト 　⇒ 実際にクエリを叩いて、想定するリクエスト が返ってくるか
14. Rails × GraphQL テストについて ② 各ObjectType ごとのテスト ・スキーマ要素 ⇒ 各Typeに定義されたスキーマ要素をテストする ・リクエスト 　⇒ エラーケースについてテストを書くのが良さそう 例）認可されていないアクセスに対して 401 を返す処理があ る場合、そのレスポンスをテストする、、など
15. まとめと今後 ・APIサーバーをAWSにデプロイする ・クライアントを作成する（React × Apollo使用予定） ・テックブログ完成