3 ms·
Maybe this is already in the works, since the enterprise plan has a logging feature, but an integrated logging solution would be nice for the other plans. Cloud
by eeeeeeeeeeeee 7y ago
Maybe this is already in the works, since the enterprise plan has a logging feature, but an integrated logging solution would be nice for the other plans. Cloudwatch isn’t perfect, but logging from a lambda worker to cloudwatch is very easy compared to, say, having to setup/manage an ELK stack for this purpose on Cloudflare.
I’d like to be able to have more than one unique Cloudflare worker per account. And be able to assign specific workers to specific routes. This feels like an odd limitation and forces you to make huge workers code with path case statements to separate the request actions out. Pretty soon a single worker starts to feel like a large app instead of a simple function that does mostly one thing.
The ability to have more than one worker or at least a “dev” worker is really showing to be important to me. Especially the more logic that is moved to the edge, the more complex it gets, and the more testing/review might be needed so you need some way to stage changes before promoting to production.
Overall though I really like Cloudflare workers. I’ve moved a project that was built on AWS and it’s mostly all an improvement on CF, especially performance which was very noticeable. I run one public API entirely on workers and I use workers on the public facing site to scrub the path users send us and 302 them to the right place, instead of having to do that in the app. I also remove most query params inside the worker to improve caching performance. I should have a use case for the KV system soon.