I’m starting a new project and looking to see if cloudflare workers + KV store are a nice fit. But mostly, my questions are around the developing flow. I’m finding the lack of documentation around this to be a bit concerning, but I also understand that it’s a relatively new project.
For context, my team has 3 engineers—two contractors and me.
In a team environment, since it’s not possible to run a local KV how can we develop against it? Do I have to create a namespace for each developer?
Since dollar shave club’s cloudworker is no longer maintained, how do we write tests?
How are you guys developing using Workers + KV in a team environment? I feel I might be missing something because right now without being able to fully run KV dev server I’m finding it quite complicated.
I was also thinking about using them for an open source project but I just can’t figure out how people would be able to contribute if they can setup a local env.
Yeah, this is a tough one and I’ve seen different variants of setups.
I’m currently developing alone, however, I had a team of coders in mind from the start…
What I do is setup VSCode ssh boxes for each coder and apply them a token with access to a specific zone and worker. Then they can pull from our git and develop their modules that’s part of a “whole”, like one module might be /reviews. To test during development, they use cloudworker.
I’m the only one on my small team using workers, been using it for a few months. At some point we had two of us developing at the same time.
The playground does not work with the cache API also, so we don’t use it much except to go examine errors that caused an exception to cause the worker to exit.
To forgo the playground we needed a substitute for console.log. I made a small service for this: https://github.com/johnelliott/http-stdout that takes a fetch request and prints to the standard output of the service process. I pair that with stern: https://github.com/wercker/stern which allows me to tail log that Kubernetes container. It’s a bit simplistic, but it’s been functional. Most of the work is wrapping fetch calls that contain the logs with WaitUntil() to allow them to get out before the worker closes.
For multiple devs, we use the per-task namespace (we use concourse CI and Kubernetes to create mini environments per GitHub PR) that we already have to allow multiple people to work at the same time. Once we create a PR and mini environment with the PR number as part of the subdomain we can create a worker on that route.
I think you’re on the right track. As for tests, the best thing I can think of is to try to keep business logic out of the way of the Cloudflare implementation and test with traditional JS frameworks.
