CF Workers seem to slowly becoming a full-blown "edge" platform. A year or two ago you couldn't really use it for much except simple cloud functions and key-value storage, but now, with WS support, S3 storage and SQL database coming along I'll be taking a second look.
Not sure why this is a surprise to people, AWS started with similar humble origins. The goal of Cloudflare has been to become the fourth public cloud for a long time now, I think in several years they will be the most powerful platform to build on.
Not really a surprise, and the platform will very likely grow further, though I wouldn't compare CF to AWS in anything except the rise in popularity. I'd say they're "reinventing" cloud in a way. From my point of view, AWS is (mostly) IaaS, likes of Heroku - PaaS, whereas CF Workers and their "ecosystem" is primarly serverless, though - with these recent additions - they're expanding what this category of tools can do. It's a unique platform for sure.
I used to work at Render, and I said often "Cloudflare is the iceberg - only ten percent of it is above the water and it's going to tear a big chunk out of the [PaaS] boat".
Over time it seems more and more confirmable as a hypothesis.
True. I was actually looking at Render a while back to host my app. The Render Disks were the one feature I was most interested in, as no other PaaS provider I was aware of provided persistent disk storage. The prices were a bit too much for a side-project though, and with no managed MongoDB, I ultimately made the app not require the disk storage and moved to Railway.
Clean - yes. Working with CF Workers was (and I think still is) a joy. However, I'm curious if, with this many features that are mostly unique to CF, will there be a feeling of vendor lock-in when developing more complex apps? Serverless functions can be usually moved back and forth pretty easily, but if you become dependent on CF-specific features how hard will it be to migrate if there comes a need to?
Note that although there is unfortunately no complete standard that we could follow for `connect()`, the API is largely based on the JavaScript streams standard. `connect()` itself returns a ReadableStream and a WritableStream representing the two sides of the socket -- both standard APIs that are widely implemented by browsers and others. Hopefully, this means that it doesn't take much to adapt code to any other API that another vendor might provide.
That is exactly my thought. As long as the APIs remain clean: SQL for D1, simple KV-store for KV etc with clear semantics, it will be agnostic. Especially since caching sits at the core.
