APIStudy#5 開催報告

Avatar
dstn

こんにちは。技術部對馬です。

去る2月21日に、APIStudy#5が開催されました。

前回の#4 の様子はこちらからご覧ください!

  

今回はゲストに乗り換え検索アプリ「駅すぱあと」でおなじみの株式会社ヴァル研究所さんを迎え、APIについて語り合いましたので、その様子をご報告します。

f:id:ytsushima:20170314132623j:plain

 

第1部 LTタイム

まずは恒例LTからです!

なんと今回はヴァル研さん含め3名が登壇してくださいました!

 

ヴァル研究所 丸山さん

最初は、ヴァル研究所テクニカルエヴァンジェリストである丸山さんから。

f:id:ytsushima:20170314132705j:plain

ヴァル研・駅すぱあとのご紹介をしていただいたあとに(運営脇野とヴァル研究所は同い年!)、

こんな駅すぱあとWebServiceAPIは嫌だ!をテーマにAPIへの思いをぶつけていただきました。

f:id:ytsushima:20170314132825j:plain

  • APIKeyが紙で届く。コピーさせてくださいよぉ
  • 自動発行されない
  • パスが直感的ではない
  • パラメータ多すぎ
  • JSONが扱いづらい…

そして最後に恐ろしい画面が…!

f:id:ytsushima:20170314132842j:plain

道理で感情がこもっていたわけですね…。

そして#5開催日翌日(2月22日)が駅すぱあとの誕生日でした。惜しかった!おめでとうございました!

 

MOONGIFT 中津川さん

中津川さんはニフティクラウドのmobile backend エヴァンジェリストで、今回はmobile backendのお話でした!

そして、SNSで以下を呟いてもらうことが本日の目標。

#NCMBすごーい

f:id:ytsushima:20170314132917j:plain

(出たな、サーバルちゃん…!)

 

というのは冗談で本当はこっち↓

f:id:ytsushima:20170314132940j:plain

 

アプリ作っていてサーバーを建てなければいけないときに、まるっとカバーできるのがニフティクラウドです。

しかしそのAPIに4つの問題があるので、そちらを紹介していただきました。

  • APIのバージョニング問題。  いつバージョンを切り替えるのが問題。
  • セキュリティ問題。  妥当性チェックのときに、APIをコールしないと正しいかわからず、ハードルが上がる。
  • 動的に変化するパス。  データストアでは勝手にクラス名をいじって保存場所を変更できる。 …が、美しくない!
  • ドメイン問題。  4つもAPIのドメインがあって管理が大変。

 

f:id:ytsushima:20170314133015j:plain

 

ヴァル研究所 伊藤さん

そして最後は、伊藤さんから「WebAPIでダブルバッファリング」について。

f:id:ytsushima:20170314133114j:plain

データのチェック処理で完了までには時間がかかるので集計途中のデータを確認したく、WebブラウザからAPIで引っ張っていました。これをバッチで並行に処理していきます。

しかしそのうちどんどん処理時間が長くなり、タイムアウトが発生してしまうようになってきます。

そこでちょっと前のデータを予め集計し公開を繰り返すようにし、リクエストとデータ更新がぶつからないように変数を分けておく必要があったと、つまりダブルバッファリングが必要だったいうお話でした。

切り替えイメージに、またしてもサーバルちゃん!!いや、これはサーバル!

f:id:ytsushima:20170314133047j:plain

すごーい!けもフレはやっぱり人気なんだね!

そして、レスポンスに時間がかかるWebAPIはどう処理するべきなのか、議論したいとのことでした。

 

第2部

さて、続いてはお待ちかねのディスカッションタイムです!

今回のテーマは…

  • レスポンスがかかる場合の方法
  • APIのサポートが増加した場合の対応
  • こんな最悪の状況いやだね!愚痴り隊
  • 複数のAPIをバラバラで使う場合の方法

そしてグループに別れ、発散発散!

f:id:ytsushima:20170314133141j:plain

f:id:ytsushima:20170314133206j:plain

 

共有タイム

 

レスポンスがかかる場合の方法

f:id:ytsushima:20170314133318j:plain

レスポンスの許容範囲どのくらいか、というのはバッチとリアルタイムによってきます。

バッチの場合は、単位が営業日単位。

リアルタイムでは、厳しいところだと200ミリsec以内。

UXも結構大事!

レスポンスを早くするためには、リアルタイムでDBにアクセスに行かないのが1つのベストプラクティス!

あとは、お客さんの許容範囲を知ることが大事。

そしてその概念を営業に植え付けとかないと「遅いって言われてる!!!」って慌てちゃうので、認識をもたせましょう。

 

APIのサポートが増加した場合の対応

f:id:ytsushima:20170314134458j:plain

サポート大変だよね問題。

  • 伝言ゲームが大変。
  • 質問が「エラーが起きたんですけど…」
  • 同じ人から何回も…

サポートの仕方はサイボウズさんがよくできているそうです! それは、コミュニティのユーザーさんが質問に答えてくれるエコシステム。

核となる人が必要なので、その人たちを見つけて意識付けをし、構築していきました。所謂エヴァンジェリストのような方々です。

見つけ方は、kintoneを作ったときに関わった人やTwitterによく書いてくれている人を…、ロックオン!

kintoneのことが好きな人に、協力いただいているそうです!

またサンプルコードを充実させるのもよいプラクティス。

Azure API マネージドはいろんな言語でサンプルコードがあるから便利かも。

AIも使えるぞ!!!! あとは、問い合わせ自体を営業にやらせて鍛えるという案も。

営業さん!!狙われています!!!

 

こんな最悪の状況いやだね!愚痴り隊

f:id:ytsushima:20170314134543j:plain

再現ができないエラー、エラーメッセージの原因がいまいちわからないあるある!

エラー時のレスポンスコードが200でその中に理由が入ってて意外とわからない…。

エラー時のレスポンス出力コーディングまちまち…。などのエラーに関するあるあるから、 仕様がバラバラなどの仕様あるあるまで、たくさん発散していました。

ドキュメントが間違っている!!

パスワードつきのExcelファイルはいけてない!!!!!

…などなど、最後の方は滾っていましたね…。

 

複数のAPIをバラバラで使う場合の方法

f:id:ytsushima:20170314134608j:plain

いろんなAPIをまとめて使って、レスポンスや結果を返すことについて。

「分散処理してマージ」を繰り返すというのが実際にあったケースで挙げられました。

あと、A社B社C社のAPIを使いたいがレスポンスがそれぞれどのくらいで来るかわからない場合、どう処理するのか?の結果が以下2つ。

  • 時系列で処理するように実装していく
  • 処理ができた順番にレスポンスを返す

WebAPIには遅延がかならずあるので、そこの処理が重要になってくるという結論になりました。

人によってAPIの捉え方が違うし、APIへの関わり方によっても違ってくるので、いろんな立場の人とAPIについて話していけると面白い!

 

おわりに

f:id:ytsushima:20170314134632j:plain

LTでまさかサーバルネタがかぶるとは思いませんでした…。

そして今回も皆さん、十分に発散できたのではないかと思います!

いろんな思いを発散することができる!それがAPIStudy!(なのかもしれない)

 

今回のグラフィックレコーディング

完成したグラレコがこちら!

今回も素晴らしくきれいにまとまってますね♪

f:id:ytsushima:20170314134736j:plain

…あれ?

… ま た い た !

                     \サーバルだよ!/

f:id:ytsushima:20170314140047p:plain

なんだかんだで今回のMVPかもしれない…

 

そして

今回は開催報告が遅くなってしまって申し訳ないです…。

その為!!!!!

次回開催が定員オーバー!

なんということでしょう!

これも皆さんが楽しそうにAPIトークをしていただいているおかげです…。

次回はさくらインターネットさんで開催します。

そしてなんと!この度#6開催の増枠が決定!(2017/03/15情報更新)

40名まで定員を増やしました!

(APIに飢えている)けものはいても、のけものはいない♪

Welcome to ようこそAPIStudyパーク!

宜しくお願いします。

コメント

ログインしてコメントを残してください。

Powered by Zendesk