Application = Workflow
Let’s say that we have a sendgrid service in the service marketplace to send emails.
And let’s say that a part of our workflow needs to send a specific type of emails to send verification codes to users to make it possible for them to verify their accounts, and let them to reset their passwords and so on.
Knowing that, think about a scenario that a user wants to reset its password. To do that we need to send a verification code to its email. After user receiving this email that contains the code, it should enter it in a mobile app or website and be able to set a new password for its account if the verification code is correct.
To make this possible, devs need to generate a verification code in their workflows maybe with a help of another service, keep this code in a database by using a database service and send the code to user with an email by using the sendgrid service. And check the code entered by the user while password is being changed.
As we see, to implement this feature we need these two sendgrind and mongodb services and introduce some business logic directly into the workflow.
Proposal In Short
- Allow workflows to be reusable.
- Create a marketplace for reusable workflows.
Proposal In Long
My proposal here is to allow devs to create reusable workflows so they’ll not be required to duplicate same logic in their different workflows(projects).
With this reusable workflows, we can simplify the code verification feature we talked about in the Problem section by creating a reusable workflow like below:
workflow id(wid): email-code-verification
workflow services (the services that workflow uses): sendgrid, mongodb
- sendVerification ([ inputs>
- verifyCode ([ inputs>
code string]) ([ outputs>
email string]) // returns email if code is exists and not expired
Reusable workflows are just like reusable services. They have tasks, task results and events. They can be used by other workflows like how services are used inside workflows. They can also have deployment time configurations. They’re easy to create with a GUI and can be deployed to workflow marketplace.
This reusable workflows idea is very similar to service composition but there are some major differences:
- It is possible to use multiple services in a reusable workflow and not just only one(this is the case in service compositions).
- It’s easier to create workflows rather than services. Because a GUI will be available to create workflows for non-programmers.
- We’ll have a service & a workflow marketplace growing naturally and separately. Services will stay more generic because we’ll have this strong separation between the services and workflows. On the other hand, service composition will result services to be less generic(opinionated) which is a very bad adoption and will create a noise in the service marketplace.
We can also make this reusable workflows to be compatible with the current
service(listenTask, submitResult) &
core(listenResult, listenEvent, executeTask) APIs so we don’t need to create more gRPC APIs or logic in the Core.
Details About Reusable Workflows
- Reusable workflows can be created over a GUI.
- Reusable workflows can use other reusable workflows or services and listen for their results or events and execute their tasks.
- Reusable workflows can be used by regular workflows just like how regular workflows uses services.
- Reusable workflows can receive configurations in the deploy time.
- Reusable workflows acts like services so they’ll share the same
core(listenResult, listenEvent, executeTask)APIs with services.
- There is no much difference between regular workflows and reusable ones. They are deployed/started/stopped/deleted in the same way. The difference is, workflow syntax will let devs to define some tasks and emit some results or events from a workflow. This way, they can be used just like services. Reusable workflows gives the possibility to combine multiple services together and create an opinionated one.