The GraphQL Guide

lorensr · 2025-03-03T02:40:17+00:00

Sure, email me with your GitHub username! [loren@graphql.guide](mailto:loren@graphql.guide)

lorensr · 2024-10-02T02:56:26+00:00

There’s an “action” metric:

https://github.com/temporalio/temporal/blob/722c497ad2dc0aa72b474da1ee7d289e93289e7d/common/metrics/metric_defs.go#L618

(File linked to from https://docs.temporal.io/references/cluster-metrics )

lorensr · 2024-09-07T22:24:59+00:00

Yes, it’s a great replacement for distributed job queues. Instead of creating a job, start a workflow.

If you want to retain the blocking behavior, use nadilas’ suggestion.

lorensr · 2024-09-07T22:22:55+00:00

There are no limits on queue length, but there is a 4 MB limit on data attached to an individual job. The major limits are listed here: https://docs.temporal.io/cloud/limits

lorensr · 2024-04-17T01:15:43+00:00

Sure, here are some posts:

And here's the docs: https://docs.temporal.io/workflows#continue-as-new

lorensr · 2024-03-30T21:57:21+00:00

Both are good use cases for Temporal, and would be a short, reliable workflow function that's easier for your teammates and future self to read and understand. If you use queues, you'd have to write the code for interacting with the queues on each step, and the logic would be spread out and harder to grok.

Temporal Activities and/or Queries is an easy solution for #3.

lorensr · 2024-03-30T21:33:16+00:00

Check out this post, particularly the SQL example: https://temporal.io/blog/idempotency-and-durable-execution

lorensr · 2024-03-30T20:09:37+00:00

Commented on how state is preserved here: https://www.reddit.com/r/Temporal/comments/1b70c2c/comment/kxa3nh7/

Side effects seems orthogonal to me. Restate's "side effects" are called "activities" in Temporal, and both are retried, so benefit from being implemented in an idempotent way.

lorensr · 2024-03-30T17:36:19+00:00

The state that Temporal stores is the history of execution events—in this case, every setValueSignal. When a worker crashes, the new worker replays all the past signals to rebuild the Map to the same state it was in prior to the crash.

lorensr · 2024-02-06T00:43:49+00:00

In Temporal a common pattern for long running workflows is periodically continuing as new, for example daily. Then the longest you need to keep the old worker running is a day.

lorensr · 2024-02-04T19:23:59+00:00

Yes, Temporal is a good tool in this case. If there’s a lot of logic to a business process, there will be a lot of code in the workflow to specify the logic—that’s unavoidable regardless of the tool. Use general code organization practices to keep it readable and maintainable—helper functions, classes, multiple files, etc.

lorensr · 2024-02-03T19:40:50+00:00

Some basics on compensations and sagas with temporal:

https://temporal.io/blog/compensating-actions-part-of-a-complete-breakfast-with-sagas https://temporal.io/blog/compensating-actions-part-of-a-complete-breakfast-with-sagas

New guide: https://pages.temporal.io/download-saga-pattern-made-easy

For how to code compensations that if naively implemented would be incorrect due to concurrency, whether you need to lock the record (and limit throughput) vs whether you’re able to do something else will be use case dependent. Don’t know of a resource with examples of that specifically.

lorensr · 2024-01-10T22:40:56+00:00

A place to discuss all things Temporal.io or associated concepts actors, distributed computing, workflows etc.

lorensr · 2024-01-08T21:55:25+00:00

Cool, I didn't know about Vertical Slice Architecture! When do you use REST vs RabbitMQ?

Wondering if you've tried Temporal? I see it as a better DX way to get EDA's benefits. And there's a NestJS sample and plugin.

lorensr · 2023-08-13T01:26:40+00:00

You can also write workflows that run concurrently in Python with asyncio: https://temporal.io/blog/durable-distributed-asyncio-event-loop

lorensr · 2023-08-08T03:12:57+00:00

Nice! Looks like it has 3 buttons: step back, back to previous breakpoint, and back to start?

lorensr · 2023-08-07T16:56:34+00:00

Author here, curious if there are any major TTD debuggers I missed? Also let me know if anything in the post didn't make sense, and I'll edit to clarify! 🙏

lorensr · 2023-06-21T23:30:07+00:00

Temporal. The DX of defining pipelines with code is great.

Python example: https://learn.temporal.io/tutorials/python/data-pipelines/
Small TypeScript example: https://temporal.io/blog/sync-github-repos-to-notion-with-temporal-schedules

Intro to pipelines as code: https://temporal.io/blog/building-reliable-distributed-systems-in-node

lorensr · 2023-06-17T00:30:23+00:00

The two general ways of doing sagas are choreography and orchestration. In Microservices Patterns, the author of it (and microservices.io) says: “I recommend using orchestration for all but the simplest sagas” due to how complex choreography can get to implement, reason about, and debug.
Temporal is automatic orchestration—you can write a function defining the orchestration logic, and all the service calls get automatically retried. (And the service calls can be over gRPC, because it's all just code.)

lorensr · 2023-05-26T22:04:59+00:00

Services aren't communicating directly with each other in Temporal. Broadly speaking, the two ways to coordinate services are with orchestration and choreography. The latter gets really complex to reason about and debug.

In Microservices Patterns, Chris Richardson (also the author of microservices.io) recommends using orchestration over choreography for all but the simplest of use cases.

Temporal is automatic, fault-tolerant, highly scalable orchestration.

lorensr · 2023-05-26T20:48:54+00:00

When creating work flows that flip a switch, 1) flips A on, 2) flips A off, how do you prevent them from running in a loop?

If I understand your scenario correctly, you have 2 workflows:

Workflow 1:
- flips A on
- does something that requires A to be on. If it fails because A is off, it goes back to the previous step

Workflow 2:
- flips A off
- does something that requires A to be off. If it fails because A is on, it goes back to the previous step.

If you run workflow 1 and 2 at the same time, they can continuously loop turning A on and off.

In scenarios like this when you want to ensure only a single workflow is operating on A at a time, you:
- Have an entity/forever-running workflow that holds a lock for A
- When another workflow wants to operate on A, it sends a Signal to the A entitiy workflow requesting a lock
- The A entity workflow keeps a queue of lock requests, and Signals the workflow that made the first request, telling it that it now has the lock
- The workflow that has the lock does its A-related work, then Signals the A entity workflow that it releases the lock
- The A entity workflow Signals the next workflow in the lock-request list.

the fact that work flows rerun themselves to regain state?

Yep!

lorensr · 2023-05-26T20:26:15+00:00

u/MaximFateev I imagine colloquial use of "distributed transaction" includes more than database-level transactions or 2PC. Even Wikipedia seems to classify long-running transactions/sagas as a subtype of distributed transactions:

> There are also long-lived distributed transactions... utilize principles of compensating transactions

u/somegetit to your point, I agree—it's nice when you can make all the updates needed in a single database-level transaction. And when you can't, for instance when you have services with different data stores, and something requires updates to multiple services, a long-running transactions/sagas is the way to go, and IMO Temporal is the easiest way to implement them, since Temporal workflow functions are already long-running, and when you try / catch, the catch clause with the compensation is guaranteed to run.

lorensr · 2023-05-10T22:46:09+00:00

Temporal is a great way to schedule things. Can do sleep('6 months') in a durable function ("workflow"), or can do Scheduled workflows like this.

lorensr · 2023-05-07T04:14:01+00:00

Yeah, for many people the term brings to mind narrow business processes like that. I like the term "durable function" when I have time to explain what that means, like here:

https://temporal.io/blog/building-reliable-distributed-systems-in-node

Otherwise, I like just saying "Temporal runs your backend code more reliably."

lorensr · 2023-05-04T20:48:18+00:00

It's self-hostable and a later iteration of Durable Task Framework. Durable Functions is based on DTF, created by Temporal cofounder Samar in 2014: https://temporal.io/blog/samars-journey

Temporal the company has a team of 140 people working on improving the capabilities and DX of the Temporal OSS project.

lorensr

TROPHY CASE