Hello everybody out there using Temporal:
I’m doing a (free) framework for various workflow engines and eventing systems.
You can check out the project page here: https://nodiex.com/nx-workflows.html
And the (very early) documentation here,
- Workflow Packages: https://nodiex.com/nx-workflows_doc_workflows.html
- Requests: https:// nodiex .com/nx-workflows_doc_reqs.html (as a new user, I can only create 2 links, sorry!)
I implemented this because I want to create workflow instances dynamically with inter-service communications. Ie, receive a Request from Spring, RPC, from a Message Queue or otherwise,
and instantiate a registered, declared Workflow referenced by that request.
In addition, I think that a lot of requests that are performed in millions of lines of existing code, can fit into a pattern of request management beyond just fire and forget. Request management that can be implemented with Workflow Engines.
For example, functionality that spans multiple services, but starts off as a request to an endpoint, has to have a generic way of rolling back, terminating, etc.
Workflow engines like Temporal provide a lifecycle around this but at the moment a lot of service functionality is implemented simply with the most basic lifecycle: execute a request and handle it’s response.
In a lot of cases, this is sufficient but would benefit from some of the generic functionalities provided by Temporal without having to be refactored into a complete, custom Workflow, Activities, Stateful Execution, Saga re-implementation the Temporal way.
There is a large ammount of code that can be implemented with a general lifecycle.
Essentially, the purpose of nxWorkflows is to implement a Request Gateway that accepts requests from various protocols, and faciliates the lifecycle of the Request with your preferred Workflow Engine.
At this time, I implemented with Cadence and Temporal, and though I think Temporal is great piece of software, it isn’t a fact that it can necessarily provide the total functionality every user would want from a Request Management perspective (due to the fact that it cannot know all possible internal Request Toplogies of various networks), nor is it necessarily the final implementation for this type of software.
By wrapping requests in a framework like nxWorkflows, you may be able to:
- Implement additional functionality to your Request Lifecycle specific to your Request Topology
- Benefit from efforts to provide different but potentially valuable Request Lifecycles provided by other Workflow Engines
- Continue to execute endpoint requests in your inter-service communications, without completely refactoring to the Temporal Pattern, but benefit from Temporal functionality
As such, I implemented a base, generic, Request Handler Workflow that takes a Request object (built from a call to an endpoint) and executes it in an Activity. The Request Handler can call a third party Service or
call a method in the JVM, but the point is that the Request Handler is executing within the Temporal Lifecycle and benefits from the functionality provided by Temporal (retry, distributed cron, etc).
I intentionally implemented this with Kafka Consumer/Producer initially, because this is the most generic way of interacting with Kafka and the hope is that people would dive into the code and modify it to their inter-service topology as necessary. I intend to implement with Kafka Streams, and other Messaging Services shortly.
In addition, the documentation is relatively sparce because at this time, this is a simple, but in my opinion, generically useful implementation. Again, my hope is that you use it to implement Workflows and Requests for your particular needs by using the source.
Though, it may make sense to add declarative features, the intent is it provide code that is useful in the context of an SDK. Code that is read, understood, modified by implementing developers.
Thank you for reading this, please let me know if you have any feature requests.
My immediate intent is to add additional documentation, publish to artifacts to Maven, implement integration with Spring and other popular frameworks, add some examples or a sandbox.
In addition, we are interested in working with customers and partners implementing systems with Temporal and other Event Processing middleware. If you would like to partner with us, please reach out here or at [admin @ nodiex .com].