chronark_

4 ms·

1. 1.▲
   by chronark_ 1y ago

   It’s faster for non-colocated customers too weirdly I think cause connections can be reused more often. Cloud flare workers are really prone to doing a lot of TLS handshakes cause they spin up new ones constantly Right now were just hang aw
2. 2.▲
   by chronark_ 1y ago

   Thanks It’s totally fair criticism that the title and wording is a bit clickbaity But that’s ok
3. 3.▲
   by chronark_ 1y ago

   Yeah that’s fair
4. 4.▲
   by chronark_ 1y ago

   I cofounded it yeah And yeah you’re right in hindsight it was a terrible idea to begin with I thought it could work but didn’t benchmark it enough and didn’t plan enough. It all looked great in early POCs and all of these issues cropped up
5. 5.▲
   by chronark_ 1y ago

   Oh we had it coming for quite some time and knew we would need to rebuild it, we just didn’t have the capacity to do it unfortunately. I was working on it on and off moving one endpoint at a time but it was very slow until we hired someone
6. 6.▲
   by chronark_ 1y ago

   I doubt they literally said “perfect for low latency APIs” but their messaging is definitely trying to convince you that they’re fast globally, just look at the workers.ckoudflare.com page
7. 7.▲
   by chronark_ 1y ago

   Not everyone is born with experience in distributed systems
8. 8.▲
   by chronark_ 1y ago

   I can assure you that was pretty close to the internal conversation lol Not sure what the different takeaways would be though?
9. 9.▲
   by chronark_ 1y ago

   We did initially but thought cloud flare was a better solution for scalability and latency. We believed their docs/marketing without doing extensive benchmarks, which is on us. The appeal was also to use the same typescript stack acros
10. 10.▲
    by chronark_ 1y ago

    Author of that blog here, happy to answer any questions :)