4 ms·

Sounds like, if they don't make their solution open, this will become the basis for a fairly nice little framework. It'll be interesting because this will requ

Sounds like, if they don't make their solution open, this will become the basis for a fairly nice little framework. It'll be interesting because this will require significant rework to fit with how most web servers work. It would be hard to implement in NGinX, for instance. Facebook probably just wrote a custom server, or heavily modified the code to an existing one.

nathanieljones 16y ago
Second paragraph: Although BigPipe is a fundamental redesign of the existing web serving process, it does not require changing existing web browsers or servers; it is implemented entirely in PHP and JavaScript. So it may be a good candidate for a library. I guessed they were doing something similar a few months ago when Facebook first started showing up block by block. Interesting to see it all laid out.
aristus 16y ago
It's actually webserver-neutral, implemented entirely in PHP and Javascript. The basic idea is that each "pagelet" does its own data fetching and rendering and returns a thunk of HTML, js & css dependencies, onload hooks, etc, as a data structure (JSON or what have you). As each pagelet completes it is flushed down the single network connection to the client using HTTP chunked encoding. The Javascript half of BigPipe catches those flushes, handles the dependencies, registers handlers, and slaps the HTML into place. This lays the groundwork for many things like incremental page updates, parallel execution, and so on.
WALoeIII 16y ago
I think you could actually implement this with nginx + <insert evented/actor server (tornado, rainbows, mochiweb, yaws etc.) here> + your application quite easily. Nginx buffers the client's request (you cannot turn this off) before passing it to the backend but you can turn proxy_buffering off which stops nginx from buffering the response to the client. In this middle tier you could instantly send the headers + loading JS and flush the buffer then determine the pagelets to render and either do it in process or further delegate to application servers with HTTP or your own protocol. This does kind of beg the question, why use nginx at all? It provides you with a lot of protection against malformed requests and general fuckery. If you need it you can push the middle layer back into nginx as a module which would be screaming fast. This reminds me of Heroku who do something like this with their 'routing mesh.' client -> nginx -> routing mesh (erlang) -> thin (ruby app server). The erlang process knows which ec2 instance has the ruby process to serve the request and initiates and is basically a smart proxy. You could quite easily query 6 backends simultaneously for each pagelet and pipe the JSON out to the client then throw in the footer as well. I think this deserves some experimentation. nginx + erlang + rails (serving JSON).
- piotrSikora 16y ago
  Actually, you can implement this with nginx + client-side JavaScript to merge "sub-pages" right now, you don't need any server-side language or framework. Guys from Taobao (http://www.taobao.com http://www.taobao.com) have open-sourced pretty much everything you need to do that: - ngx_echo (http://github.com/agentzh/echo-nginx-module http://github.com/agentzh/echo-nginx-module) for asynchronous pipelining, - ngx_drizzle (http://github.com/chaoslawful/drizzle-nginx-module http://github.com/chaoslawful/drizzle-nginx-module) for fetching data from Drizzle/MySQL/SQLite, - ngx_postgres (http://labs.frickle.com/nginx_ngx_postgres/ http://labs.frickle.com/nginx_ngx_postgres/) for fetching data from PostgreSQL, - ngx_rds_json (http://github.com/agentzh/rds-json-nginx-module http://github.com/agentzh/rds-json-nginx-module) for converting database-responses into JSON. Also, this isn't new concept, at least few Chinese companies I know of use similar rendering process.
  - liuliu 16y ago
    With all respect to the people in taobao, but this is different. The whole page (without css, JavaScript and images) in facebook case generated through one http request. In your case, they use Ajax to get content through serveral http requests. IMHO the facebook method is better. It avoid http request overhead and parallized steps as many as possible.
    - piotrSikora 16y ago
      You must have missed ngx_echo module, because it's the part that makes this exactly as described in Facebook's BigPipe blog post. I've prepared simple proof-of-concept configuration for nginx: http://labs.frickle.com/misc/nginx_bigpipe.conf http://labs.frickle.com/misc/nginx_bigpipe.conf As you can notice, every "sub-page" is generated individually. Using presented configuration everything is chunked and flushed, so it will be sent to the client right away. Response on the client side looks like this: http://labs.frickle.com/misc/nginx_bigpipe.output http://labs.frickle.com/misc/nginx_bigpipe.output DISCLAIMER: I don't know how Taobao is using released modules internally or if they use them in production already (but I know some portals do).

nathanieljones 16y ago

Second paragraph: Although BigPipe is a fundamental redesign of the existing web serving process, it does not require changing existing web browsers or servers; it is implemented entirely in PHP and JavaScript. So it may be a good candidate for a library. I guessed they were doing something similar a few months ago when Facebook first started showing up block by block. Interesting to see it all laid out.

aristus 16y ago

It's actually webserver-neutral, implemented entirely in PHP and Javascript. The basic idea is that each "pagelet" does its own data fetching and rendering and returns a thunk of HTML, js & css dependencies, onload hooks, etc, as a data structure (JSON or what have you). As each pagelet completes it is flushed down the single network connection to the client using HTTP chunked encoding. The Javascript half of BigPipe catches those flushes, handles the dependencies, registers handlers, and slaps the HTML into place. This lays the groundwork for many things like incremental page updates, parallel execution, and so on.

WALoeIII 16y ago

I think you could actually implement this with nginx + <insert evented/actor server (tornado, rainbows, mochiweb, yaws etc.) here> + your application quite easily. Nginx buffers the client's request (you cannot turn this off) before passing it to the backend but you can turn proxy_buffering off which stops nginx from buffering the response to the client. In this middle tier you could instantly send the headers + loading JS and flush the buffer then determine the pagelets to render and either do it in process or further delegate to application servers with HTTP or your own protocol. This does kind of beg the question, why use nginx at all? It provides you with a lot of protection against malformed requests and general fuckery. If you need it you can push the middle layer back into nginx as a module which would be screaming fast. This reminds me of Heroku who do something like this with their 'routing mesh.' client -> nginx -> routing mesh (erlang) -> thin (ruby app server). The erlang process knows which ec2 instance has the ruby process to serve the request and initiates and is basically a smart proxy. You could quite easily query 6 backends simultaneously for each pagelet and pipe the JSON out to the client then throw in the footer as well. I think this deserves some experimentation. nginx + erlang + rails (serving JSON).

piotrSikora 16y ago
Actually, you can implement this with nginx + client-side JavaScript to merge "sub-pages" right now, you don't need any server-side language or framework. Guys from Taobao (http://www.taobao.com http://www.taobao.com) have open-sourced pretty much everything you need to do that: - ngx_echo (http://github.com/agentzh/echo-nginx-module http://github.com/agentzh/echo-nginx-module) for asynchronous pipelining, - ngx_drizzle (http://github.com/chaoslawful/drizzle-nginx-module http://github.com/chaoslawful/drizzle-nginx-module) for fetching data from Drizzle/MySQL/SQLite, - ngx_postgres (http://labs.frickle.com/nginx_ngx_postgres/ http://labs.frickle.com/nginx_ngx_postgres/) for fetching data from PostgreSQL, - ngx_rds_json (http://github.com/agentzh/rds-json-nginx-module http://github.com/agentzh/rds-json-nginx-module) for converting database-responses into JSON. Also, this isn't new concept, at least few Chinese companies I know of use similar rendering process.
- liuliu 16y ago
  With all respect to the people in taobao, but this is different. The whole page (without css, JavaScript and images) in facebook case generated through one http request. In your case, they use Ajax to get content through serveral http requests. IMHO the facebook method is better. It avoid http request overhead and parallized steps as many as possible.
  - piotrSikora 16y ago
    You must have missed ngx_echo module, because it's the part that makes this exactly as described in Facebook's BigPipe blog post. I've prepared simple proof-of-concept configuration for nginx: http://labs.frickle.com/misc/nginx_bigpipe.conf http://labs.frickle.com/misc/nginx_bigpipe.conf As you can notice, every "sub-page" is generated individually. Using presented configuration everything is chunked and flushed, so it will be sent to the client right away. Response on the client side looks like this: http://labs.frickle.com/misc/nginx_bigpipe.output http://labs.frickle.com/misc/nginx_bigpipe.output DISCLAIMER: I don't know how Taobao is using released modules internally or if they use them in production already (but I know some portals do).