There are cloud providers, I have personal experience using sendgrid.

For small scale / personal stuff you can use gmail's SMTP.

https://support.google.com/a/answer/176600?product_name=UnuF...

Firebase free tier, you can create an scheduled function that runs your python code and sends the email.

Super easy to deploy and it is set and forget.

I'm sure you can fit your use cade in the free tier.

It means having serving your users from the edge of the network, close to them.

Not necessarily tied to v8 isolates, for example fly.io and others let's you run any container on "The Edge".

I think CDNs were the original concept but the name evolved away from "content" to indicate that you can run your business logic too

> "Tunnels offer protection from wind and rain."

Not sure about this one. Back home in Guadalajara Mexico a lot of tunnels get flooded during rain season. I'm talking about 6ft of water.

To be fair, even streets turn into rivers / pools.

I'm developing an alternative using SQLite, focused on JavaScript developers productivity.

https://javascriptdb.com

What's the difference/advantage between defining the virtual column or creating the index directly like this:

CREATE INDEX test_idx ON events(JSON_EXTRACT(data, '$.someKey'));

The two things are actually independent of each other: you can create a virtual column and an index, or do only one. The generated column can be used as an alias of an expression in queries (e.g. ORDER BY clauses), while just creating an index cannot. The generated column can be optionally virtual (although that defeats the purpose listed in this article), while the index is obviously always stored. The generated column reduces the likelihood that you accidentally don't use the index, because "the SQLite query planner will consider using an index on an expression when the expression that is indexed appears... exactly as it is written in the CREATE INDEX statement." [0]

[0] https://sqlite.org/expridx.html

I think the way the article does it just provides an easy, symbolic way to reference the computed value... so it gives a little readability, it's maybe easier to ensure your where clause and index match up.

Also, depending on your access patterns, you might want the generated column to be stored (evaluated on write) rather than virtual (evaluated on read).

SQLite doesn't support adding generated stored columns to a table once the table has been created, so you basically have to decide upfront which generated columns must be stored, and then you can't touch it anymore (short of dropping it).

That’s normal DBA for SQLite - you can’t even rename columns without dropping the table. So not such an obstacle.

You can rename it now, unless I'm missing something

https://www.sqlite.org/lang_altertable.html

For a start, the top level of the JSON document could be an array.

That doesn't matter. The json_extract function returns a string, so json_extract('[{"foo": "x"}]', '$.foo') is NULL and json_extract('[{"foo": "x"}]', '$[0].foo') is 'x' and it doesn't matter if this is destined to go into a generated column or an index.

[append] And SQLite's json_extract doesn't have anything like '$[*].foo' or any mapping functions. You could use json_each to do that, but the process is very different from creating an index.

Fair, but for objects like in the OP sample? Is there any advantage that justifies the extra steps?

I think the advantage for simple objects is just that you can refer to the columns directly vs having to go through a function. It's only really a big win if you're manually writing a lot of sql or if you're using something like Rails and you want to write queries against values in the JSON blob without going through a bunch of hoops.

If SQLite gets you excited, I'm building a firebase alternative based on sqlite. I'm betting hard on sqlite so this get's me super excited!!

https://javascriptdb.com

CF people around, I would love to chat, if anyone is interested please reach out at: jp@javascriptdb.com

I'll be applying to this beta for sure!

Super interesting! I really like the idea. I'll join the beta, email sent :)

Any feedback on what do you find interesting would be awesome :) thanks!!

Hey Josh,

I'm building a serverless firebase alternative that uses SQLite. If CF gives me access I will totally support D1 & workers.

Check it out: javascriptdb.com

Thanks! I'll check it out.

I'm building an open source firebase alternative using sqlite. I'll be reaching out, I was thinking to build the distribution & durability part myself, but I would rather use D1!

I guess it would count as a client focused ORM :)

I'll be reaching out from jp@javascriptdb.com

Great addition, congrats!

I think the most successful attempt would be Realm.

https://realm.io/