From reading the linked article it seems fairly easy to use. Do you have some concrete examples why your solution would be "lighter"? I'd actually say it's heavier since you have to pay and end up in a "custom pricing scheme" (whatever that means) for 10k+ users as it says on your website. And it's also only available as a cloud service, with all the vendor lock in shenanigans everyone hates.
By the way people usually disclaim upfront on HN (see FusionAuth folks here) when they are involved in a project. Seems like you are the "CTO at Clerk". Frankly it's dishonest to talk bad about open source without claims to back it up while also being in a competitive space and plugging your solution in their "Show HN" moment.
didn't mean to talk bad... nothing but respect for everyone involved in this project. my comment was very hasty -- and you're right I should have disclosed up front that I'm working on a product in a similar space.
Ory has been around for awhile, they're quite the gorilla in the identity space - It's a set of very large, and very impressive products that work well together. It is extremely powerful, flexible, and can handle almost any use case. I'd define "lighter" as being more opinionated in it's approach with fewer options - as a result it's less powerful and flexible. Also, w/ open source, comes setting up your own infra (even if that's now just throwing it in a cloud), which I'd consider "heavier". Imo, these terms don't mean something is worse than something else, just a fit for a different use case.
Awesome to see an open source project in this space! However, the docs say the service is production ready and v1, yet there seem to be no docs on how to run the open source version (except for a brief homebrew example in the README). So how do I run this? For example with a DB?
I also noticed that the v0 API is deprecated and discouraged but the v1 API is „work in progress“. To me, that doesn’t inspire confidence that the product is not going to have some breaking changes in API and design?
We have it on our backlog[0] to add documentation on how to run it with Kubernetes, at least.
Very sorry about the "work in progress" moniker on our v1 APIs. We developed the v1 APIs based on our real-world experience running the Authzed.com service for ourselves and others, and we just finished their implementation and porting everything over. We will remove that warning ASAP!
One thing to note though, is that we thought about calling our v1 APIs v5 or something, because we didn't want to give the impression that they will never change. We intend to continue to improve the APIs, sometimes in backward incompatible ways, but will just keep the existing APIs around for a very long™ period of time, similar to how Stripe handles their API versioning.[1]
By the way people usually disclaim upfront on HN (see FusionAuth folks here) when they are involved in a project. Seems like you are the "CTO at Clerk". Frankly it's dishonest to talk bad about open source without claims to back it up while also being in a competitive space and plugging your solution in their "Show HN" moment.
tl;dr no thanks I'll look somewhere else...