トップ > Geeks Who Drink -Public API Edition- に参加しました。

Geeks Who Drink -Public API Edition- に参加しました。

少し時間がたってしまったのですが、先日開催されたGeeks Who Drinkにブログレポーター枠で参加してきました。 イベント内容はこちら。
https://nulab.connpass.com/event/83120/

GraphQL for Backlog

  • Jalal Chaabane さん（　Nulab inc. Software Engineer　）

英語のセッションだったので理解しきれない箇所もあったのですが、デモもあり分かりやすかったです。
主に「GraphQL for Backlog API」の話と、実際にGraphQLを使ったデモを見せてもらいました。
以下、簡単なメモ。

  • GraphQLとは？
    • Facebookが作ったクエリ抽出用言語。
    • REST APIの代わりにQuery言語でデータをやりとりできる。
  • Backlog4s
  • GraphQL for Backlog API
  • Demo
    • GraphQLのクエリを書いてBacklogAPIを実行 ⇒ 実行結果がJSONで返却される。

GraphQL、名前は知っていたけれど使ったことがなかったのでデモなど見てイメージが沸きました。
SQLに馴染みがあるので、意外といいかも？と思いましたが、トーク後の質問でも出ていた「キャッシュ」や「トランザクション」などがどう関連してくるのか、REST-APIと比べてどこまでメリットがあるか、などは気になるところでした。

お前はこれまでに作ったAPIの数を覚えているのか？

  • 高山温さん ( ピクシブ株式会社 CTO兼福岡オフィスマネージャー )

ピクシブでのAPI開発の歴史がよくわかるお話でした。公開APIと社内用APIで考慮するべき点が違ったり、現在に至るまでに いろいろ辛そうな部分もあったんだなーと思いました（今自分が開発している製品も古いデータ取得方法からREST-APIへの変更などをしていたりするので参考になる部分も多かったです）

  • PHP -> JS API（2010年ごろから）
    • 型定義がなく、arrayをjson_encodeしたものだった。
  • CSV API
    • 拡張時は側にカラムを追加、使わないカラムは空白で並ぶ、など。
    • 社内のwikiにカラム定義を書いていた。
    • 2010年ごろはJSONが主要ではなかったので、レスポンスサイズが小さく済むCSVを採用したのではないか（と思われる）
  • Public API（2012年ごろ）
    • CSV APIをやめて、スマホアプリ向けAPIを作ることになった。
    • API公開を求められることが多くなったので、公開APIを作成し、アプリからもそれを使うことにした。
    • ドキュメントはMarkdownで書いた。
    • しかし失敗・・・
      • 不特定多数の開発者が使うことを想定したが、一般公開しなかった。
      • 提携企業と自社サービスでしか使わず、隠しパラメータなどがドキュメントに反映されない状態になった。
    • LSUDs（大勢の知らない人向け）・SSKDs（少数の知ってる人向け）
    • 社内API
      • 社内のサーバ間通信APIをThriftで構築。
        • サーバのインターフェース実装だけ作ればよい。
        • 実装とドキュメントの乖離が生まれない。
      • Thriftはバイナリなのでcurlでちょっと叩くとかのデバックが面倒。
  • 現在のAPI
    • 極力シンプルに。DB呼び出し関数を数個読んで、JSONを作るだけに特化。
      • CQRS(コマンドクエリ責務分離)
      • Swagger定義は必ず書く。
  • API定義の自動テスト
    • SwaggerをRSpecでテスト：乖離がないことを担保。
    • Swagger API定義を書いて、レスポンスの型（JSONスキーマ）用の検証ツールをテストで叩いた結果と突き合わせて、仕様を満たしているかをテストできる。
      • キーが増えてドキュメント書き忘れたがなくなる。
      • リファクタリングが楽。
  • To REST or Not To REST
    • こだわる必要はなし（Railsつかうならやってもいいんじゃない？くらい）
    • 大事なのはSwagger書くことくらい。
    • いまからGraphQLはうーん・・・（少数向けには、という意味）
  • まとめ
    • 社内でしか使わないAPIならシンプルに。
    • APIドキュメントは絶対に書こう。

Swaggerについては会場内でもちらほら反応があったので、使っている人が多いのかな、という印象でした。
個人的にはapiaryなどを導入検討したりしていたのですがあまりうまく進んでいなかったので、Swaggerをちゃんとやったほうがいいかな、と思うきっかけになりました。

APIを利用して、生産性を生み出す技術

  • 山下和彦さん（　GMOペパボ株式会社 ホスティング事業部 CTL　）

GMOペパボの中で、APIを使って生産性を生み出している話。
会社の中でGitHubAPIを有効活用しまくっているのだなーと。Slackひとつとっても、単なるチャットツールではなくChatOpsをしっかりやっている話が聞けて面白かったです。

  • GitHubの話
    • ソースレビューを定期化。
      • 多い日で３０回くらいレビューしないといけない。
      • しかし、レビュー依頼は基本的に割り込みタスクー＞生産性を阻害してしまう。
        • 割り込みを計画されたものにする（レビューする時間を決める。割り込みを防ぐ）
    • OctokitでGitHubAPIを使う。
    • 評価資料
      • furik APIで実績を自動出力。
      • GitHubの活動を数値化ー生産性の定量化。
    • ドキュメントイメージの管理。
      • スクリーンショットを撮ってGitHubに自動アップロードするコマンド作った。
  • コミュニケーションツールをまとめる。
    • Slack／GitHub／Twitter
    • Gmail
      • 大事なメールが来たりする。サポート終了とか。決済失敗とか。
      • 見落としを無くすために、本文や件名を正規表現マッチしてSlackなどに通知。
  • Slack
    • Slack API + Ruboty
      • カスタマーサービス担当者ががエンジニアとやりとりせずにサーバ移設作業などを判断できるように（カスタマーサービス担当者が顧客にフォーカスできるように）
      • Slackから問合せて移設先のサーバを探す作業を探すAPIを作り、Slackに返す。
      • ジョブ実行指示も自動化できる。
    • Slack APIを利用したChatOps。
      • Issueのピックアップ
      • コード資産のデプロイ
      • サービスAPIのWrapper（curlの代わり）
  • TypeTalk
    • Ruboty ✕ TypeTalkはなかったので・・・作った！
      • TypeTalkはドキュメントが充実しているので作りやすかった。
  • まとめ
    • ChatOpsで職種を超えて生産性を上げる。
    • ソフトウェアで解決する。人でやらない。
    • 世の中にないものは自分で手を動かして作る。

必要なものは自分達で作る、人の手でなんとかするのではなく、ソフトウェアで解決する、
エンジニアにとってみればとても大切なことで、それが会社全体の文化として出来ているって素晴らしいなーと思いました。

その他、gRPCやRed Hatでの取り組みなどのLTも聞きました。
APIをテーマにしたトークってどんな感じなんだろう、と思いつつ参加したイベントでしたが、
APIを作る側・使う側、それぞれの話が聞けて満足度が高かったです！！

Photo

f:id:nako0123:20180430003731j:plainf:id:nako0123:20180430003735j:plainf:id:nako0123:20180430003737j:plainf:id:nako0123:20180430003740j:plainf:id:nako0123:20180430003742j:plain