Vlákno názorů k článku Mikroslužby založené na REST API od prochac - Také jsem čekal více, třeba nějaké návrhové vzory. Stále...

Také jsem čekal více, třeba nějaké návrhové vzory.
Stále si u používání REST pro mikroservisní architekturu lámu hlavu, jak asi implementovat kompenzační transakci pro PUT/PATCH.
Furt mě to tíhne k obyčejnému JSON-RPC. Případně není důvod nepoužít gRPC nebo, kdo nerad Google, Thrift

Pokud je to dlouho běžící "transakce", tak proč to nenamodelovat jako eventy (v event sourcingu tomu vzoru říkají Saga)? POST pak nezapisuje přímo data, ale dává požadavky do fronty. Ten event pak může být nastavení odložené akce, když se něco nepovede (nebo vyprší čas).

Něco jako:
POST /users registrace uživatele -> 201 Created; id
-> POST /queue smaž uživatele id v čase t+1 den -> 202 Accepted

po potvrzení emailu:
-> POST zruš příkaz na smazání uživatele (nebo rovnou DELETE)

Ale jak uděláte kompenzační transakci na PUT/PATCH, když nevíte předchozí stav?

11. 7. 2019, 16:31 editováno autorem komentáře

Ale vy víte výchozí stav. Protože tu kompenzaci vytváříte už během zápisu změny, jen ji nastavíte jako zpožděnou nebo podmíněnou. A pak ji případně jen zrušíte.

Uvedl jste tu nejednodušší variantu, kdy na POST/CREATE máte kompenzační transakci DELETE.

A myslím si, že jste nepopsal SAGA pattern, ale 2PC https://en.wikipedia.org/wiki/Two-phase_commit_protocol
Tady jako commit nakonci smažete naplánované kompenzační transakce.

Saga udržuje nějaký stav automatu a emituje další akce. V mém případě je jedna taková schovaná, ten požadavek na potvrzení emailu se někde přece musí evidovat. Takže vznikne nějaký záznam stavu někde (saga) - v reakci na event EmailPotvrzen se ukončí. Její reakce na event Timeout zase spustí tu kompenzaci (resp pošle event UživatelSmazán).

Uznávám, že v tom komentáři to nebylo dost důkladně rozebrané. Ale tento přístup umí řídit i složité procesy.

Pokud to je nějaký proces rozdělený na kroky anebo déle běžící proces tak tam asi opravdu pomůže SAGA:

- https://microservices.io/patterns/data/saga.html

11. 7. 2019, 15:09 editováno autorem komentáře

Ano, ale by jste implementoval SAGA pattern, tak musíte mít kompenzační transakce.

Dobrý den,

jak píšou kolegové, buď se dá použít SAGA nebo přímo kappa architektura (https://www.root.cz/clanky/zpusoby-ulozeni-dat-v-aplikacich-zalozenych-na-mikrosluzbach/#k14), ale to už záleží na konkrétních požadavcích (protože někdy to vypadá, že potřebujete transakce a nakonec se ukáže, že to vlastně není nutné).

Ano, vím co je SAGA pattern, ale abych ho mohl implementovat, potřebuji kompenzační transakci. Tedy smazat vytvořené, obnovit smazané, vrátit změněné do původního stavu. Tyto funkce bych měl vytvářet spolu.
Proto mi zde REST přijde nevhodný a do budoucna jako i možný technický dluh. Neboť netuším, jak bych dělal reverzní akci na PUT/PATCH když nevím původní stav.

A Event Sourcing v tomhle nepomůže?

Ano, ale abych se choval tak, jak praví REST, tak budu volat POST pro vytvoření záznamu o modifikaci/mutaci. Možná by pro tento případ asi šel použít PATCH. Ale PUT není editace, to je kompletní nahrazení daného resource.

https://www.thoughtworks.com/insights/blog/rest-api-design-resource-modeling
není tak kotva, tak hledejte REST without PUT and CQRS

A když už dělám takovéhle ústupky, není lepší se na celý REST vyprdnout a dělat JSON-RPC?
REST je určitě super jako API nad datovým skladem, ale v mikroservisách ho nechápu.