I used to be a very fast (and accurate) typer, and the very first thing that makes me aware of aging is the drop of typing performance.

I wouldn't say that I'm up there in age, as I'm only 33, but I do think that I typed away faster when I was about 18 to 19 and gaming every day. But that the way that I typed led to issues with my wrists and hands later on.

I never had any dedicated typing classes like I know some younger people get now (like my younger brothers), so I just learned by doing and while I could touch type I had a bastardized technique that had my hands flying around all over the keyboard.

Nowadays, I type around 20-30 WPM lower, going down from closer to 120 to 140 to closer to consistently 90 to 100, but my technique is completely different than the past.

Will reading a lot eventually makes you want to write? I haven't found that yet.

Isn't "plan for a future" a now activity?

Hi, I'm the co-creator of this toolkit. Yes, in many ways ZenStack can be considered as an alternative to Supabase. The main differences are:

- At runtime, it's a library that runs inside your current framework (Next.js, Express, etc.), so no extra hosting is needed.

- It doesn't embed a database. You bring your own - any DB supported by Prisma.

One thing that goes beyond Supabase/PostgresRLS is that it supports column-level security as well. You can write rules to control CRUD permissions at the field level. This provides a much finer-grained control granularity.

And, yes, the DX of Prisma is a very good thing to have :D.

Very cool. Thanks for following up!

Author of the article here. I'd like to clarify that the article is meant to be about SQL databases only, although I enjoy reading the comments comparing SQL/NoSQL.

Also, "edge" means edge deployment environment/runtime like CloudFlare workers, Vercel Edge Runtime, etc. Not sensors, etc.

Hi, we don't change Prisma's query syntax as of today, so there's no native support for geo queries. We may start to extend the query syntax in the future, though. GIS query is a very popular ask.

Thanks, and great you brought up convex.dev. I really like the product.

Here're a few key differences:

- ZenStack (MIT) and Prisma (Apache-2.0) are open-source, convex announced the plan to open up, but most of it seems still close-source.

- Convex is a hosted service with a built-in relational database. ZenStack requires you to have a separately hosted database - the benefit is that you can use any supported database type and choose from many hosters.

- Schema is optional for convex.dev, but mandatory for ZenStack. Not requiring a schema may speed up initial prototyping, but you'll almost always need one when your app goes beyond a toy, and adding it at a later stage may cause inconsistency.

- Authorization is the user's responsibility when using convex - you define queries as JS/TS functions and should implement access control in those. ZenStack promotes modeling authorization declaratively inside data schema, so you can centralize them - easier to manage and evolve down the road.

In short, convex.dev makes it easy for you to write serverless functions to access databases. ZenStack focuses first on providing an access-control-enabled database client and, based on that, gives you an automatic API layer.

My apologies for the long answer. Just trying to cover every important aspect .

Thanks for the comments. Great point about Prisma compatibility/future-proof.

First of all, ZenStack doesn't include or depend on any specific version of Prisma. You can freely use any version >=4.0.0.

Our decision to base ZenStack on Prisma has two implications: 1. We need to keep up with the changes in Prisma schema (design-time) 2. We need to keep up with the changes in Prisma Client (runtime)

For #1, Prisma's schema has been quite stable, at least since it reached V4. New features barely result in changes in the schema language. Quite often, they're guarded with the "previewFeatures" option, and that's pretty much it.

For #2, at runtime, ZenStack enhances Prisma client by creating a transparent proxy around it and intercepting CRUD calls that need to be guarded/injected. Again, that part of runtime API has been very stable for quite a few releases, so as long as the semantics of those APIs don't change, nothing needs to be done for new Prisma releases. However, there're cases where we need to keep up with new features. E.g, the new release of Prisma Pulse added a new "subscribe" API for live changes subscription, and we're working on adding it into the scope of access control.

That said, we need to (and do) keep a close eye on any schema/runtime changes that may require a timely follow-up.

Hope this explains, and let me know if anything is unclear.

clear enough, thanks.

Cool name and nice looking site! Looking forward for the signup to recover.

To be honest, I feel you'll be a great asset to any startup with a small team. It's probably hard to find a good match in this economic downturn, but all the best!