Port to Drupal 7

That's impossible I'm afraid :)

You could do BigPipe in Drupal 7, but it would require tons of custom code, and the vast majority of modules won't be compatible with it; they'd have to write special code to support it. So, writing a generic module does not make sense.

https://github.com/LionsAd/render_cache/tree/7.x-2.x/modules/renderer/re... is the closest you will probably get in Drupal 7.

It was the predecessor of the BigPipe that is now here, but won't work automatically out-of-the-box.

@techopsph you can try https://www.drupal.org/project/authcache - it's a really great framework and works pretty nicely out of the box.

authcache is great, but has nothing to do with BigPipe.

@Fabianx the way authcache works is pretty much BigPipe :)

#7: No, authcache uses a seperate ajax request, which is fine and can be cached in the browser, but it is not the BigPipe technology of streaming content.

While authcache for many blocks would get to the limit of several ajax requests simultaneously (though there is some grouping logic as well if I understood znerol correctly), BigPipe can scale to as many things as you want.

This would be similar that an AjaxPlaceholderStrategy is not the same as BigPipe, nor would an EsiPlaceholderStrategy be.

Interesting, didn't know that detail, thanks for clarifying that.
(but other than that, authcache is still a nice framework though :)

#9: To elaborate a little more on when BigPipe is appropriate and AJAX is not as much.

Consider a page with 5 elements that are uncacheable inside the main content, lets also assume each of those elements takes 100 ms for simplicity reasons.

With SingleFlush (without placeholders) the order of rendering is:

- Main Content
- Element 1,2,3,4,5
- Blocks
- Html Page

With Placeholders the order already is:

- Main Content
- Placeholders for 1,2,3,4,5
- Blocks
- HtmlPage (now cacheable)

- Element 1,2,3,4,5

So 30 ms (DPC) + 500 ms == 530 ms

With BigPipe you just take advantage of the changed order:

- Main Content
- Placeholders for 1,2,3,4,5
- Blocks
- HtmlPage (now cacheable)
- Create HTML DIV placeholders for normal placeholders

FLUSH CONTENT (after 30 ms)

- Element 1 (130 ms)
- Element 2 (230 ms)
- Element 3 (330 ms)
- Element 4 (430 ms)
- Element 5 (530 ms)

So the request itself and the performance characteristics of the application do not change.

With a naive (non-streaming) AJAX implementation you either have:

- One request for each - while the user gets his data a little faster - you also have 5 times the load on the server as there are many uncacheable requests.
- Or one request for all, then the user needs to wait 500 ms till the content appears.

So the biggest innovation in Drupal 8 we have introduced with placeholders is that we re-order the page rendering without changing any underlying code.

That makes BigPipe / ESI, etc. then almost "trivial" to implement (there is still a lot of details, but in general the complexity of the problem is reduced a lot).

Also for BigPipe especially you can even placeholder things that depend on the state of the application (not dynamic page cacheable, then though) as again only the order is changed, but all happens in the same request.

This also gives potential for the future:

- As soon as a placeholder is created, it stays a placeholder.

So in an async system like HHVM one could take advantage of that by starting to render placeholders in the background whenever the database / cache / filesystem is busy waiting for something.

That would not make the main page faster, but would take care of "wait" times - in theory at least. And ready placeholders could then directly send, while the rest is BigPipe'd and continued to be processed in the background.

This issue and its comments were an interesting read. Thanks guys. For Drupal 7 I'll check whether Authcache https://www.drupal.org/project/authcache is fit for my use case.