Cloudflare Workers and their KV service (https://www.cloudflare.com/products/workers-kv/) is great. I built a side project (https://tagx.io/) completely on their services from hosting the static site, auth flow and application data storage. KV is pretty cheap as well starting around $5/month with reasonable resources.

I am also very interested in using worker + kv. Can kv be used as a proper application database? Has anyone ever done that?

If by application database you mean to the level of an RDBMS then no. It's a key-value data store. You get your CRUD operations, expiry, key listing and the ability to do pagination with keys always returning in lexicographically sorted order. Any relation data you want to have would be using the key prefixes, e.g.:

  article:1 -> {"user": 1, "content": "..."}
  user:1 -> {"name": "username"}
  user:1:articles -> [1, ...]

yep. thats the plan. i will have keys like

postid:someid/text

postid:someid/author

etc.

the relation aspect doesnt daunts me. As long as I can have a list/collection as a value, i can define a working schema.

I am more worried about if its costlier than normal dbs. and if there are any other gotchas to keep in mind as kv workers have scant documentation.

If you're comparing this to a normal DB, the biggest worry should be that it's not ACID compliant. Definitely something to consider if your data is important. The limitations for KV is listed here: https://developers.cloudflare.com/workers/about/limits#kv

You should also consider how you intend to backup the data as there currently isn't a process to do that outside of writing something yourself to periodically download the keys. This will add to your usage cost depending on what your strategy is, for example, backing up old keys that gets updated vs only new keys by keeping track of the cursor.

I've seen tagx a couple of times before. Awesome to know who the author is.

I've heard many good things about Cloudfare Workers.

Excuse my ignorance & N00Bness, but are they essentially a Cloudfare version of AWS Lambdas, Google Cloud Functions and Netlify functions, or are they something different/better?

IIRC Cloudflare Workers run at each Cloudflare PoP, which have higher geographical density than AWS regions, so latency experienced by end-users may be lower.

AWS has the same thing with Lambda@Edge

According to this[0] blog post Lambda@Edge has significantly longer latency (due in part to a smaller number of locations). Cloudflare also uses V8 isolates instead of whole VMs, so much lower overhead. Disadvantage is that you can only run JavaScript and WASM.

[0]: https://blog.cloudflare.com/cloud-computing-without-containe...

Nice. Will check them out. IIRC they are really affordable too (like all serverless stuff tbh)

More lightweight. It’s just v8 so there’s basically no time for warm up time.

They have vastly more pops than Amazon, so global performance for these is on a different level. But they are also more limited in compute and serve a slightly different purpose.

Here https://youtu.be/U1EFgCNLDB8

I've done a couple neat (IMO) things with CF workers.

- I use imgix to manipulate images in my app, but some of my users don't want anyone to be able to discover (and steal) the source images. Imgix can't do this natively; all image manipulation instructions are in the URL. So I put a CF worker in front of imgix; my app encrypts the url, the worker decrypts it and proxies.

- A year ago, intercom.io didn't support permissions on their KB articles system. I like intercom's articles but (at the time) wanted to restrict them to actual customers. So I put a CF worker in front that gates based on a cookie set by my app.

These are both trivial, stateless 5-line scripts. I like that I can use CF workers to fundamentally change the behavior of hosted services I rely on. It's almost like being able to edit their code.

Of course, this only works for hosted services that work with custom domains.

> I like intercom's articles but (at the time) wanted to restrict them to actual customers. So I put a CF worker in front that gates based on a cookie set by my app.

Might be against their terms? I rem someone asked if they could treat Workers as a http reverse-proxy to essentially bypass restrictions, and the answer was "no".

Seems unlikely. But if they really want to lose paying customers, that would be one way of doing it.

It’s pretty incredible. You can put it over any site and build your own A/B testing or targeting based on the user or the link used to get to your site.

>These are both trivial, stateless 5-line scripts

Would it be possible to share these scripts? I would love to see them, they sound really helpful/useful

Sure. Here's the help system one (no longer used since intercom now supports permissions, and I opened up the help system anyway):

    addEventListener('fetch', event => {
       event.respondWith(handleRequest(event.request))
     })

    async function handleRequest(request) {
       const cookie = request.headers.get('Cookie');
       if (cookie && cookie.includes('foo=bar')) {
         return await fetch(request);
       } else {
         return new Response('You must log in before accessing this content');
       }
     }

The encrypted URL script is actually a bit longer than "5 lines" (it has been a while) so here's a gist:

https://gist.github.com/stickfigure/af592b1ce7f888c5b8a4efbe...

Utilized workers to create one of the fastest website analytics tool after Google Analytics: https://rapidanalytics.io (still in development).

Fast, as in what sense? The tracking code loads fast? The tracking requests are sent fast to the server? The dashboards load fast?

At my company, we run 100% of our front-end React/Vue web apps on Cloudflare workers - We love it, deploys are really easy, performance/resilience is built-in

Why rust over go?

Different use cases.

Go was designed to be easy to use for un-demanding problems. People mostly switch to Go from Ruby, Python, or Java; or from C in places where C was an unfortunate choice to begin with.

Rust is gunning for C++ territory, in places where the greater expressiveness of C++ is not needed or, in cases, not welcome. They would like to displace C (and the world would be a better place if that happened) but people still using C at this late date will typically be the last to adopt Rust.

So you’re saying it should have better performance than go?

I am mainly saying it is suitable for solving harder problems than Go. Most problems are not hard; Go is good enough for them, and easier to learn and use well.

All these languages are Turing-complete. The difference is in how much work it is to design and write the program, and in whether it can satisfy performance needs.

C++ wins here by being more expressive, making it better able to implement libraries that can be used in all cases. Rust is less capable, but stronger than other mainstream languages.

Sometimes. Better control of performance.

Easier to search for if nothing else.