goloroden

Thank you very much :-)

AFAICT there are already a few in the making :-)

Thanks :-)

I think two different meanings of "capabilities" are getting conflated here. In the HATEOAS sense, capabilities are the state transitions a server advertises via hypermedia links – an API discovery mechanism, not an authorization model. Roles and permissions are orthogonal to that and of course still enforced server-side on every request. A server that takes hypermedia seriously only advertises links the current user is actually allowed to follow, which is arguably a security plus.

Also worth noting: that sentence was just a historical aside about Fielding's original definition. The actual argument of the piece is that what most people call REST is really CRUD over HTTP, and that commands and queries are a better fit.

I entered my zip code… well, wrong country: I’m living in Germany.

And even if you knew that, the only thing you could have known from the zip code is the city. At least roughly, because multiple small villages share one zip code.

Or, to cut it short: This doesn’t work at all on a general and global level, so I guess there’s a reason why websites do this differently…

There are a number of strategies, some described here: https://docs.eventsourcingdb.io/best-practices/gdpr-complian...

No. Was your comment AI-written?

(I'm asking because it's super annoying that some pseudo-smart people come up with an oh-so-clever approach of "look ma, I have detected AI slop" over and over again, when all they actually do is piss people off who write by hand.)

Thank you very much :-)

Sad but true.

And maybe as well https://www.cqrs.com

If you want to, reach out to me via mail: golo.roden@thenativeweb.io

Maybe I can shed some light on this :-)

Haha, that’s true :-)

You can find a pretty detailed overview with some examples in the documentation: https://docs.eventsourcingdb.io/reference/eventql/

Regarding GQL… which (accidentally :-D) has almost the exact same syntax as EventQL (the query language of EventSourcingDB), which was published earlier. See https://docs.eventsourcingdb.io/reference/eventql/ for details.

What a coincidence… ;-)

Just a little hint: Read the other comments as well…

Just a little hint: Read the other comments as well…

Hi there,

I’m one of the creators of EventSourcingDB, and the CTO of the native web (the company behind EventSourcingDB).

Because of ongoing legal investigations I can’t comment any further, but I’d like to provide you with some links, so you can see for yourself:

https://www.eventsourcingdb.io

https://docs.eventsourcingdb.io

https://hub.docker.com/r/thenativeweb/eventsourcingdb

https://www.cqrs.com

https://www.eventsourcing.ai

I think I’d call what Tesla did fraud. Or scam. Or both.

It’s not even 2 lines:

1. Type definition 2. Chain definition 3. Enqueue definition

I „solved” it by ignoring a part of the problem?

Please don’t take this personal, but IMHO that’s not solving the problem. That’s coming up with a workaround.

After years of building systems with CQRS and event sourcing, we kept running into the same roadblocks: Missing concurrency control, unreliable ordering, complex snapshotting, no native replays. So we built a database purpose-built for event-sourced systems – and wrote up how it compares to Kafka, Postgres, MongoDB, and others.

We’ve just released EventSourcingDB 1.0 – a new database designed from scratch for event sourcing projects. It focuses on simplicity, consistency, and performance, while eliminating external dependencies like message brokers or coordination services.

Key features include:

– Append-only event storage with strict immutability and global ordering

– Atomic writes across multiple streams with built-in concurrency control

– CloudEvents-compliant HTTP API for writing, reading, and observing events

– Live subscriptions with long polling, recursive stream support, and replay capabilities

– Snapshots and versioned schemas for evolving data models

– Secure by default: HTTPS enabled, API token protected, read-only fallback on license expiry

– Minimal operational footprint: no brokers, no coordination layer, no external runtime

– First-class observability: OpenTelemetry, Prometheus, and automation support

– Runs anywhere: Linux, macOS, Windows; x86 and ARM; Docker or native binary

EventSourcingDB is free for small projects (up to 25,000 events). A commercial license is required for larger projects.

Documentation and downloads: https://docs.eventsourcingdb.io

I built a love story „movie“ using the Office assistants from a C# program.

Later that year we got married, and we still are - 14 years later

For the backend I'd use wolkenkit, a backend framework for JavaScript that lets you build backends very quickly: https://github.com/thenativeweb/wolkenkit

To get started, you find everything you need in the documentation, see https://docs.wolkenkit.io/3.1.0/

There is also an existing sample application that you might use as a starting point: https://github.com/thenativeweb/wolkenkit-boards

For the frontend I'd use React, probably, just because it is the UI library / frontend I'm most familiar with and the one I value the most.

PS: Please note that I am one of the core developers of wolkenkit, so please take my answer with a grain of salt.

Yes, currently it's still like this, but it's on our roadmap to change this in the near future (I'm one of the core developers of wolkenkit).

It is the only one (I know of) that provides an all-in-one integrated approach that "just works".

Actually, inspired by your comments, I'm currently sitting at my desk, thinking about how to improve the claim.

I would love to discuss things with you. If you are interested in exchanging ideas as well, feel free to contact me via mail (hello@thenativeweb.io).

PS: I like "Wolkenkit is a framework that allows you to save and replay your entire business's history so you never miss a key insight again." :-)

Thanks for the idea!

What might also be interesting is https://www.youtube.com/watch?v=rolfJR9ERxo

Well, the point here is: The reason why you should use it, because of the benefits of CQRS and event-sourcing – and unfortunately, at this point, I think you need to get your feet wet and learn about these concepts ;-)

Maybe https://docs.wolkenkit.io/3.0.0/getting-started/understandin... is a good place to start.

I think one thing that is also important here is (and this also may sound harsh, but is not meant to be offensive): If you don't know what CQRS and event-sourcing are, you probably don't have the problem that CQRS and event-sourcing solve ;-)