3 ms·
I like using Workers for smallish http services. The uptime, pricing, and latency are fantastic. I would never use them for anything complex as the vendor lock
by pier25 2y ago
I like using Workers for smallish http services. The uptime, pricing, and latency are fantastic. I would never use them for anything complex as the vendor lock in is quite strong and the dev experience still needs to improve.
Containers on the edge with low cold starts, scalability, the same reliability as Workers, etc would be super cool. In part to avoid the lock in but also to be able to use other languages like Go (which Workers don't support natively).
- catskull 2y agoWorkers use the web worker API so theoretically there’s less lock in. I’ve also found wrangler pretty good, what problems have you run into?
- pier25 2y agoYou can't really run the Worker code without modifications somewhere else afaik (unless you're using something like Hono with an adapter). And for most use cases, you're not going to be using Workers without KV, DO, etc. I've hit a bunch of issues and limitations with Wrangler and Workers locally over the years. Eg: https://github.com/cloudflare/workers-sdk/issues/2964 https://github.com/cloudflare/workers-sdk/issues/2964 https://github.com/cloudflare/workerd/issues/1897 https://github.com/cloudflare/workerd/issues/1897
- tarasglek 2y agoThis is why I switched to deno deploy. Much of the same benefits and much more portable stack.
- pier25 2y agoIt's great you can run Deno anywhere you want. Their KV service is phenomenal too. Personally I don't want to keep using JS in the server anymore. As more time passes I feel like TS is a hack compared to the elegance of something like Go.