A real-world comparison between Cloudflare and Fastly

A real-world comparison between Cloudflare and Fastly(barstool.engineering)

23 points by andrewbarba 4 years ago | 5 comments

kentonv 4 years ago |

Nice post. I like the focus on developer experience rather than just performance.

Workers' implementation of pipeTo() is indeed optimized to avoid entering the JavaScript isolate at all during the operation. I agree this probably explains the performance difference here.

For setting `Content-Length` on a streaming response, Cloudflare has a non-standard extension called `FixedLengthStream`. It works the same as an identity `TransformStream` except you pass the expected stream length to the constructor.

Example: https://cloudflareworkers.com/#c2a014c7f67df83f9ad3ea90e9c60...

We would of course prefer to implement a standard API here, but at present there doesn't seem to be one.

(I'm the tech lead for Cloudflare Workers.)

andrewbarba 4 years ago | |

Wow thanks so much for pointing out the fixed length stream. I had been talking with a few people on your team and no one pointed me to that. That entirely solves our problem to getting things into production. Thanks a ton

kentonv 4 years ago | | |

Yeah it's not well-known nor well-documented since it's non-standard. There's a bit of debate about whether and how to document it... but don't worry, it won't disappear.

fyrn- 4 years ago |

I didn't dig into the benchmark, but this seems to use typescript which fastly I think claimed in the inital post was "beta"? I would be interested to see how this compares to fastly with rust/wasm as their more mature system, even if that would also inherantly not be apples to apples (not that you can ever have that with something like this anyway)

aliswe 4 years ago |

Anyone care to summarize?