表示中のページから https://techracho.bpsinc.jp/baba/2014_10_08/19139/amp にリダイレクトしようとしています。 このページにリダイレクトしないようにする場合は、前のページに戻ってください。
リダイレクトの警告
表示中のページから https://techracho.bpsinc.jp/baba/2014_10_08/19139/amp にリダイレクトしようとしています。 このページにリダイレクトしないようにする場合は、前のページに戻ってください。
ssig33.com - XSendFile でそこそこ高速にファイルを配信しつつなんかやる
ファイルをそこそこ高速に配信しつつ、裏でなんか処理をしたいとか、認証をかけたいとか、そういう事情があることはそれなりにあります。 配信状況を確認したいという程度なら fluentd でログをひろってきてなにかすればいいでしょう。 ファイルをバックエンドから非同期に拾ってきつつ状況にあわせてリダイレクトしたり配信したりする 配信状況の確認処理がえらく複雑かつ同期的にやりたい 認証をかけたい とかなんとか難しい条件があると難しいという話になります。ここで本当に高速なアプリケーションを開発したい場合 nginx に拡張を書くというのが現実的な解となってくるでしょう。そういうことをするには本物の C++ プログラマーが必要ということになってきます。さらにリソースが潤沢ならば HTTP サーバーからなにから自分で書いてもよい。 ただ大体の場合そこまでギリギリの高速さが必要ではないでしょう。そこで X
GraphQLは何に向いているか - k0kubun's blog
今年GitHubがGraphQL APIを正式公開したあたりから、GraphQLが去年とかに比べちょっと流行り始めたように感じる。idobataがGraphQL APIを公開したり、Kibelaも公開APIをGraphQLで作ることを宣言している。 利用者側からすると使えるインターフェースの中から必要なものを調べて使うだけなのであまり考えることはないのだが、自分がAPIを提供する立場になると話は変わってくる。REST APIとGraphQL APIはどちらかがもう一方のスーパーセットという風にはなっておらず、どちらかを選択すると何かを捨てることになるので、要件に応じてどちらを選ぶのが総合的に幸せなのか考える必要がある。 以前趣味でGitHub連携のあるサービスを作っており、それを最近GraphQL API v4を使うように移行し、そこでついでにそのサービスのGraphQL APIを書いてみ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
