HTTP2 時代のサーバサイドアーキテクチャ考察 - Block Rockin’ Codes
update 色々と twitter で議論が起こったのでまとめて貼っておきます。 togetter.com みなさんありがとうございました。 intro HTTP2 の RFC 化も目前ということで、そろそろ実際に HTTP2 を導入していくにあたってサーバサイドの構成についても、具体的にどう変わっていくかという点を考え始めていく必要があります。 そんな話を @koichik さんとしていたら、色々と考えが膨らんだのでメモしておきます。 前提 今回は、中規模のサービスを想定し、特に HTTP2 のサーバプッシュを踏まえた上でのコンテンツ配信などに、どういう構成が考えられるかを考えていきます。 また、本エントリ内では独自に以下の表記を採用します。 HTTP/1.1 = HTTP/1.1 (平文) HTTP/2 = HTTP/2 (平文) HTTPS/1.1 = HTTP/1.1 over
Extensible Web を支える低レベル API 群 - Block Rockin’ Codes
Intro 最近 Extensible Web の話がたまに出るようになりましたが、なんというかレイヤの高い概念(ポエム)的な話が多い気がしてます。 もう少し具体的な API とか、「それコード書く上で何が変わるの？」って話があまりないので、今日はそこにフォーカスして、 Extensible Web 的な流れの中で整理された API の話をします。 しかし、実際には API が 「Extensible Web という理念で生まれたかどうか」は自明ではないので、 今標準化されている低レベルな API を拾い、それを整理するというエントリだと思ってもらと良いかもしれません。 あまり知られてない API もあると思うので、これを期に「これがあれば、今までできなかったアレが、標準化や実装を待たなくても、できるようになるな」と思ったら是非書いてみると良いと思います。 実際はそれこそが Extensi
Extensible Web の夜明けと開発者が得た可能性の話 - Block Rockin’ Codes
Web based on Standards Web は誰のものでもありません。 だれかプロダクトオーナーがいてその人が意思決定するとか、そういうのとは真逆の成り立ちをしています。 標準的な仕様を決めて、その仕様に則って Web の世界は成り立っている。 政府が作るサイトも、 Twitter も、学生が作ったブログも、全部同じルールで作られている。だから繋がる。 これって結構凄いことだと、自分は思っています。 Standarization このルールの決め方にもルールがあって、ちょっと敷居は高いかもしれないけど、誰でも自由に参加して、自由に意見を述べることができる場があります。 標準化団体ってやつですね。 なんか一部の人たちが勝手にやっているように思えるかもしれないけど、それは選挙に行かない人の理論と同じです。 あなたが仕様について意見を持ってて、それが妥当であるならば、その発言は仕様を根
Stream API がブラウザにやってくる - Block Rockin’ Codes
Intro 今日は、フロントのプログラミングスタイルに、にまた一つ大きな変化をもたらすであろう Stream という API についてです。 この仕様は現時点でまだ策定中であるため、 API は変更される恐れがある点にご注意ください。 Stream API 以前 「Node.js の Stream API で「データの流れ」を扱う方法」 という記事を書きましたが、簡単に言うとあれがブラウザにもやってくるという話です。 非同期処理おさらい もう何度も書いた話なので駆け足で。 JS はシングルスレッドでイベント駆動な世界なので、何をするにも非同期であり、コールバックを登録することで完了した結果を受け取る API が基本です。 これは、ブラウザの DOM の API でも、 Node.js でも共通しています。 概念を疑似コードで書くと以下のような感じです。 console.log('1');
なぜ html の form は PUT / DELETE をサポートしないのか？ - Block Rockin’ Codes
注意 内容については一切保証しません。 ここでは、主に W3C ML での議論や各種仕様などに基づいて書いています。 ここに書かれていることが正しいかどうかは、自身で判断して下さい。 事実としておかしいところなどは、コメントでどんどん指摘して下さい。遠慮はいりません。 ただし、このエントリでは「form が PUT/DELETE をサポートするべきかどうか？」の議論はしません。 「REST の是非」や「PUT/DELETE の意義」についても議論する気はありません。 ここでやっているのは、あくまでもどういった議論の末現状があるのかの調査です。 そうした意見がある場合は、 W3C などに投稿するのが最も有益だと思います。 History 2014/03/29: 公開 2014/03/29: XForm と XHTML の関係を明確化(thanx koichik) 2014/03/29: HT
なぜ QUIC や SPDY が生まれたのか ? - Block Rockin’ Codes
Intro Google が SPDY の開発を始めたのは 2009 年で、 2012 年に HTTP2.0 のドラフトとして採用されたあたりからちょっと話題になりました。 翌 2 月には新たなプロトコル QUIC の存在が Chromium のソースからリークしたのですが、しばらくは音沙汰なく。 6 月に入ってやっと Google から公式アナウンスとドキュメント類が出ました。 去年から今年にかけて立て続けに出てくる新しいプロトコルの話。 なぜ今 Web のプロトコルが見直されるのか？ 何が問題で、なぜ Google はそれらを作り変えるのか？ SPDY や QUIC は Google の独自プロトコルだけど、それは本当にただの独自プロトコルで終わらせていいのか？ 20% ルールで作ってみた Play プロジェクトでしかないのか？ こうした新しい動きには、かならず「それまで」と「今」を踏
Web+DB Press vol.75 で SPDY/HTTP2.0 特集を書かせて頂きました - Block Rockin’ Codes
intro タイトルのとおり、 Web+DB Press の vol.75 に Web をより速くする次世代プロトコル!!［速習］SPDY & HTTP/2.0 というタイトルで特集記事を書かせていただきました。 WEB+DB PRESS Vol.75 作者: 栗林健太郎,柴田博志,はまちや2,常松伸哉,黒田良,川添貴生,安宅啓,松下雅和,桑野章弘,Jxck,伊藤直也,佐藤鉄平,登尾徳誠,中川勝樹,奥野幹也,近藤宇智朗,堀江幸紀,後藤秀宣,渡邊恵太,中島聡,A-Listers,WEB+DB PRESS編集部出版社/メーカー: 技術評論社発売日: 2013/06/22メディア: 大型本この商品を含むブログ (8件) を見る SPDY 特集 本特集は、 Make the Web Faster という取り組みの一貫として、Google が開発している、新しいネットワークプロトコル SPDY につ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
