6 ms·
So... what actually is it? I've seen the other comments, I've clicked the links and scanned the blog posts. I get that it is a "resilient workflow engine" or wh
by shuntress 5y ago
So... what actually is it? I've seen the other comments, I've clicked the links and scanned the blog posts. I get that it is a "resilient workflow engine" or whatever.
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?
- stevekinney 5y agoFor me, the compelling part was at my last company, we'd build these complicated distributed systems with a whole lot moving pieces—any of which could go down at a moment's notice. For a complex enough system, there was sometimes more work to be done to deal with any part of the system failing than to build the system itself. Basically, we were implementing our own bespoke version of Temporal over and over again. 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.
- swyx 5y agohey! so we actually have a React + Temporal example: https://github.com/temporalio/samples-typescript/tree/main/nextjs-ecommerce-oneclick https://github.com/temporalio/samples-typescript/tree/main/n... (9 minute demo/talk here: https://www.youtube.com/watch?v=WRYozSljSpw https://www.youtube.com/watch?v=WRYozSljSpw) 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 https://www.youtube.com/watch?v=2pxZgGhT-Xo
- machiaweliczny 5y agoDoes temporal have ability to handle new input? For example someone did chargeback while my delivery workflow is running. Do I have to add guards everywhere for this? 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.
- swyx 5y agoyeah use signals https://docs.temporal.io/docs/typescript/workflows#signals-and-queries https://docs.temporal.io/docs/typescript/workflows#signals-a... example usage in a billing workflow https://docs.temporal.io/docs/typescript/subscription-tutorial https://docs.temporal.io/docs/typescript/subscription-tutori...
- machiaweliczny 5y agoThanks. I guess I could have activity to set user.hasAccess=false when I get cancel signal. 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).
- swyx 5y agoyeah, use versioning! https://docs.temporal.io/docs/typescript/patching 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
- bergundy 5y agoI like to think about it in terms of what the code for managing a shopping looks like. 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.
- djanogo 5y agoIf there is no DB how will company go about collecting metrics?, in your example what would the process to query on number of abandoned carts or after how long or after adding which product did they abandon the cart?
- swyx 5y agotemporal supports elasticsearch for arbitrary querying across workflows, or you can instrument your workflows with logging to an analytics db of your choice
- chucky_z 5y agoWouldn't you still want to actually store transactional data inside of a database? Like, you would use all the workflow stuff to do all the business logic, and the workflow(s) themselves are long-running workers which interact with the database(s). I'd imagine if anything it makes databases _easier_ to reason with, because you could shard by workflow steps or something.