4 ms·

The Java framework Flow at first I thought was off putting because it uses AspectJ to modify the bytecode but after having used it it's kind of elegant. I lik

The Java framework Flow at first I thought was off putting because it uses AspectJ to modify the bytecode but after having used it it's kind of elegant. I like how it re-runs through your decider each time with the state information filling up Promises as it goes. Helps make.sure your decider is written in a deterministic fashion to the workflow events.

guitarbill 6y ago
In my experience, Flow is truly awful. It bloats build times, and prevents incremental rebuilds. You'll curse AspectJ and Flow as your codebase grows. Stack traces become atrocious (even more atrocious than standard Java). > make.sure your decider is written in a deterministic fashion You're right, but this is easier said than done. And if it isn't, it will error at runtime.
- mfateev 6y ago
  Try temporal.io. It is just a Java library without any code generation and AspectJ. It also allows to write synchronous code while Flow was only asynchronous.
  - guitarbill 6y ago
    No thanks mate, the endless `Impl` of interfaces is giving me bad flashbacks. At least it's open source I guess. Not to mention the deployment hassle that the different workflow and activity workers represent, or how you roll back such a beast. Or even what the testing strategy looks like.
    - mfateev 6y ago
      I agree that Flow being POC had all the above issues. Temporal listened to the users and solved all of them: 1. No code generation. So, you define one interface for activities and use it for both calling activities synchronously from the workflow and to implement them. Here is how would you do it in Temporal: @ActivityInterface public interface GreetingActivities { String composeGreeting(String greeting, String name); } Workflow code: GreetingActivities activities = Workflow.newActivityStub(GreetingActivities.class) // This is a blocking call that returns only after the activity has completed. String greeting = activities.composeGreeting("Hello", name); The full source at https://github.com/temporalio/java-samples/blob/master/src/main/java/io/temporal/samples/hello/HelloActivity.java https://github.com/temporalio/java-samples/blob/master/src/m... 2. SWF or Temporal does not drive the deployment strategy. You can run all of the workflows and activities as a monolith in a single process or break them in multiple services. But it is purely your choice. 3. SWF wasn't possible to run locally. Temporal fully supports unit testing of long-running workflows with automatic time skipping and local integration testing using the service running in docker-compose.

guitarbill 6y ago

In my experience, Flow is truly awful. It bloats build times, and prevents incremental rebuilds. You'll curse AspectJ and Flow as your codebase grows. Stack traces become atrocious (even more atrocious than standard Java). > make.sure your decider is written in a deterministic fashion You're right, but this is easier said than done. And if it isn't, it will error at runtime.

mfateev 6y ago
Try temporal.io. It is just a Java library without any code generation and AspectJ. It also allows to write synchronous code while Flow was only asynchronous.
- guitarbill 6y ago
  No thanks mate, the endless `Impl` of interfaces is giving me bad flashbacks. At least it's open source I guess. Not to mention the deployment hassle that the different workflow and activity workers represent, or how you roll back such a beast. Or even what the testing strategy looks like.
  - mfateev 6y ago
    I agree that Flow being POC had all the above issues. Temporal listened to the users and solved all of them: 1. No code generation. So, you define one interface for activities and use it for both calling activities synchronously from the workflow and to implement them. Here is how would you do it in Temporal: @ActivityInterface public interface GreetingActivities { String composeGreeting(String greeting, String name); } Workflow code: GreetingActivities activities = Workflow.newActivityStub(GreetingActivities.class) // This is a blocking call that returns only after the activity has completed. String greeting = activities.composeGreeting("Hello", name); The full source at https://github.com/temporalio/java-samples/blob/master/src/main/java/io/temporal/samples/hello/HelloActivity.java https://github.com/temporalio/java-samples/blob/master/src/m... 2. SWF or Temporal does not drive the deployment strategy. You can run all of the workflows and activities as a monolith in a single process or break them in multiple services. But it is purely your choice. 3. SWF wasn't possible to run locally. Temporal fully supports unit testing of long-running workflows with automatic time skipping and local integration testing using the service running in docker-compose.