If my SQL & PHP backend serving a basic web API to a React storefront is struggling to handle customer's states (carts, lists, orders, etc) how is this going to help?
What are my engineers going to actually do?
To your point, the complexity of a SQL/PHP application is significantly smaller, but, the value proposition of Temporal is probably still there: If any part of the checkout process fails (e.g. charging the credit card, successfully triggering the order after they've charged the credit card, timing an email if there is an abandoned cart, handling the moving pieces of a return). These pieces are either handled manually by a human or you've got a decent amount of business logic in place to handle each of these edge cases individually.
The value-add of Temporal—in this case—would be that it would keep track of where the customer/order was in the overall flow of ordering something and pick up where it left off in the event that something went wrong.
when you are handling your customers' states, every purchase is a long running process, both from an ordering side and a fulfilment perspective. Work needs to be done asynchronously, or you need to wait for some condition to be met to proceed, etc. Temporal makes it so that you don't have to glue together a bunch of schedulers and queues and databases and ad hoc state machines to make that work, make it traceable/debuggable, and make that scale.
Your engineers would be able to translate your business requirements directly into workflow code (often just a function) and be able to version control, test, migrate, lint, etc, rather than have that logic spread out over a bunch of your code and infra structure. they would then register it with their Temporal workers, and then invoke/signal those workflows from your php/node/whatever application code.
i did a demo recently of what its like to translate product specs to a workflow, like @rrix is saying in another comment, its pretty fun! https://www.youtube.com/watch?v=2pxZgGhT-Xo
With event based system I would just set order=canceled and then for example cron to deliver stuff via email would not pick it up.
example usage in a billing workflow https://docs.temporal.io/docs/typescript/subscription-tutori...
I wonder how such long running workflows can be updated due to business requirements change. Say we now want to have longer trial period (so something that is not externalized via activity, like email wording for example).
https://docs.temporal.io/docs/typescript/patching
its not the simplest thing to do, and we have plans to make it simpler, but patching long running work while it is still running is inherently tricky. the good news is that at least we have a versioning story (and the failure mode is stopped progress) rather than handrolled systems which basically have “deploy and pray” strategies
Without Temporal, you store the state of the cart in the DB, load it when the app interacts with your backend, run some business logic and serialize state back into the DB.
With Temporal, first of all, there's no DB. The entire flow is modeled in a single piece of code. Your Workflow can listen to user signals to update the cart, queries to get the cart state, schedule durable timers to remind a user that their cart is abandoned after days and months.
I'd imagine if anything it makes databases _easier_ to reason with, because you could shard by workflow steps or something.