Will Concurrent ESI be possible once HTTP/2 is implemented?

Comments

2 comments

  • Rogier Mulhuijzen

    Hey Rylan,

    First of all, excellent post! Your questions make a lot of sense.

    Unfortunately, I'm going to have to disappoint you. First of all, HTTP/2 is going to be front-side only for a while. And even if we did H2 to the backend, parallel ESI includes would still require a lot of additional work to add as a feature.

    What about 25 simultaneous XHR requests over H2?

    Cheers,

    Doc

  • schmylan

    Thanks for the info Doc. That helps. Unfortunately, XHR won't cut it for us. I was looking for these changes in our API to be transparent to our clients, some are 3rd parties, some are native mobile clients.

    It's no worries though. I'm always on the lookout for when new technologies turn today's best practices into tomorrow's anti-patterns. (Not that ESI is new by any stretch.) This was an exploration of memcache on the edge. A fun thought experiment but, perhaps, before its time. I've seen other (lesser) CDNs offer concurrent ESI but instant purge is the other critical component, which they do not have.

    If we were to put a CDN in front of our API, I think the best way to go would be to use surrogate keys. This way we could still insta-purge any responses that included a stale product.

    Example for https://api.example.com/products?q=blue suede shoes HTTP/1.1 200 OK Surrogate-Key: products/1111 products/2222 products/3333 ... Content-Type: text/html ...

    And then purge any responses that that might contain a newly stale product with: ``` PURGE /service/id/purge/products/2222 …

    ```

    Rylan

Please sign in to leave a comment.