Hi there, really excited by Temporal but struggling to find a large sample application built with it (I do see all the great use cases, and realise it is being used). However, I don’t see a recommendation of storing data externally to the workflows, mainly for querying and then exposing that data from a graphql API.
It is very hard to give generic recommendations without understanding your use case. If you share your requirements I can give you more specific advice.
Hi Maxim, use case will be a financial mobile app, obviously the workflows are ideal for long running onboarding processes and for orchestrating payments and transactions, but I feel that they could also be used as long running financial products, e.g. modelling a credit card or a savings account, especially where there are periodic events where fees are charged and interest is accrued and applied.
However most mobile apps I build would query this data via a GraphQL API, now say I have a customer who has multiple products (current, savings, credit, loans) - I would like to show in the app the current status of them.
I’m trying to work out, if the data should be queried from each workflow, or if a read-only database would be better - I haven’t seen many examples of this, so perhaps it’s an anti-pattern. I haven’t researched yet the ability to query data from a workflow at a point of time, and from a regulatory / reporting perspective, I think an external database will be required anyway.
AFAIK immutable append-only ledgers are frequently required for financial transactions. So using workflow for current information and an external DB for historical data is the way to go.
One important pattern is to always update these external DBs from workflow code. So if you need to issue an update don’t update DB then start/signal a workflow. But always start/signal workflow which in turn should update the DB and perform other actions. This way multiple types of race conditions and failure scenarios are eliminated.
Also, workflows should not rely on external DBs to decide what to do next. They should keep all the relevant information inside and use these DBs as information sinks.
Thanks, will start prototyping in that direction.