質問: 下記の仕様のAPIの設計をどうしたらいいかアドバイスをいただきたいです。 ### APIの仕様 * をGETで叩くと、 urlパラメーターで指定したページのスクリーンショット画像を閲覧できるurlをjsonで返却する(スクリーンショットした画像をAWSのS3などにアップロードし、そのURLを返す) * このAPIでは、このURLをスクリーンショットとってね、ということ以外に処理をする(そっちはレコード一個作るくらいなので重くない処理) * クライアントから数秒間は画像が見れなくても大丈夫 * なるべく短いレスポンスタイムにしたい ### APIの叩き方 * iOSやAndroidなどのクライアントから非同期通信でAPIを叩く * APIの戻り値は現状でハンドリングしてなく、遅くなってもUXは悪化しない + 画像を遅延読み込みみたいな感じで表示させるので、そこのUXは悪化しますが ### 懸念 * スクリーンショットを取得するのに、サーバー側でPhantomJSなどを使うとレスポンスタイムが3秒はかかってしまう * レスポンスタイムが長いため、普通にAPIとして作るとサーバー側の負荷が心配 ### こんな設計? 1. APIを叩いた時に、スクリーンショット取得するURLをキューにため、そのAPIはさっさとレスポンスを返す。キューにたまったURLをデーモンで処理し次々とスクリーンショットを取得。iOSやAndroidからは定期的に「スクリーンショット取れましたかAPI」を叩いて、さっき自分が送ったURLのスクリーンショットが取得できているかどうか確認する 2. 1ではクライアントから、スクリーンショットとれたー?というAPIを叩いていたが、それをせずに、デーモンでスクリーンショット取得後にPush通知でiOSやAndroidに知らせる 3. 普通に最初のリクエストでスクリーンショットとるところまでやって、レスポンス返す(レスポンスタイム長くなりますが) 4. socket通信 5. 他に何かよい案があればお願いします。 ### 補足 Rails4.2.6をAWSのEC2上で動かしてます。
回答: 原理としては * 多少の待ち時間はあきらめてリアルタイムで処理する * バックグラウンドに回し、処理完了を -- クライアントがポーリングする -- クライアントにプッシュする のどれかまたは併用しかありません。 いずれにしてもメリットデメリットがありますので、アプリケーションに合わせて選択するしかないです。 複雑なことをやればやるほど不具合も起きやすくなるので、負荷の心配が将来的な物なのであればとりあえず簡単な方法にしておくというのも選択肢です