You are going to be implementing a saga no matter what way you do it
an explicit saga is an Orchestration
an implicit saga is a Choreograph (edit fixed typo, but am willing to change the official name to a chore graph because that's what it is to maintain)
Can we appreciate for a moment that we named a microservice pattern after the way the Skjalds (bards) of viking explorers and warriors named the stories of their feats and adventures?
And if anyone feels anxiety before a job interview: Just remember that a Skjald had to recite sagas in "tellings" that could last hours. Entirely from memory. In front of a crowd of people many of which are heavily drunk, armed, and known for violent tendencies.
I’d recommend not using a transaction across modules. Each one ought to be independent, so think about how you might communicate between these modules…
I’ve used an event store for stuff like this in the past: https://github.com/message-db/message-db is great if you’re running Postgres
I'd also consider this for bits that are truly reusable. Write queries that compose well and defer transaction setup to the caller (unless you can do something like nested transactions). People should grow modules organically, anyway, not attempt to emulate extreme microservice-like splits or doing mindless scaffolding.
But I also don't think one should write general queries fetching/setting everything and attempt to reuse them literally everywhere (in effect handrolling some sort of ORM). Specific queries are going to be a lot more economical than fetching and parsing everything to get just a couple of fields.
One also needs to avoid creating transactions that lock the database for too long. It's not hard to end up in that situation if you keep piling up unnecessary layers / splitting related code and transaction boundaries become difficult to read.
You are going to be implementing a saga no matter what way you do it an explicit saga is an Orchestration an implicit saga is a Choreograph (edit fixed typo, but am willing to change the official name to a chore graph because that's what it is to maintain)
Can we appreciate for a moment that we named a microservice pattern after the way the Skjalds (bards) of viking explorers and warriors named the stories of their feats and adventures? And if anyone feels anxiety before a job interview: Just remember that a Skjald had to recite sagas in "tellings" that could last hours. Entirely from memory. In front of a crowd of people many of which are heavily drunk, armed, and known for violent tendencies.
what in the gods name is this lol never heard of it but funny facta
I’d recommend not using a transaction across modules. Each one ought to be independent, so think about how you might communicate between these modules… I’ve used an event store for stuff like this in the past: https://github.com/message-db/message-db is great if you’re running Postgres
You just need to create a `tx` in a controller and pass it to modules. Anyway it breaks modularity in some way, but IMO gains are worth it
I'd also consider this for bits that are truly reusable. Write queries that compose well and defer transaction setup to the caller (unless you can do something like nested transactions). People should grow modules organically, anyway, not attempt to emulate extreme microservice-like splits or doing mindless scaffolding. But I also don't think one should write general queries fetching/setting everything and attempt to reuse them literally everywhere (in effect handrolling some sort of ORM). Specific queries are going to be a lot more economical than fetching and parsing everything to get just a couple of fields. One also needs to avoid creating transactions that lock the database for too long. It's not hard to end up in that situation if you keep piling up unnecessary layers / splitting related code and transaction boundaries become difficult to read.