A common pattern is to have a Portal Task in a workflow that consumes nothing, and produces nothing. The Portal Task, still, is useful, as it can respond to portal requests, and also send requests to other portals. This is such a common pattern, that it would make sense to create an instance of it for the experimental DSL, and once we are confident with the pattern, move it into the DSL.
See the following example, some terminology may change over time, but the principles remain the same for this pattern.
// within the context of an ApplicationBuilder (e.g. using PortalsApp)
val portal = Portal[Req, Rep]("myPortal")
val workflow = Workflows[Nothing, Nothing]()
.source(Generators.empty[Nothing].stream)
.replier(portal){ _ => ??? }{
e =>
val response = ...
reply(e)
}
.sink()
.freeze()
This is a pattern which has been repeated over and over.
Instead, I would suggest the following API to be included in the experimental DSL:
val portal = PortalWorkflow[Req, Rep]("myPortal"){
e =>
val response = ...
reply(e)
}
Here, the intent is clear, all we want is to define a stateful Portal Task which replies to the Portal.
A common pattern is to have a Portal Task in a workflow that consumes nothing, and produces nothing. The Portal Task, still, is useful, as it can respond to portal requests, and also send requests to other portals. This is such a common pattern, that it would make sense to create an instance of it for the experimental DSL, and once we are confident with the pattern, move it into the DSL.
See the following example, some terminology may change over time, but the principles remain the same for this pattern.
This is a pattern which has been repeated over and over.
Instead, I would suggest the following API to be included in the experimental DSL:
Here, the intent is clear, all we want is to define a stateful Portal Task which replies to the Portal.