0

It seems to be common sense that hiding commands (i.e. triggers for actions such as calling a serverless function) in events is an antipattern. Applying the event pattern for user interactions (event: "user has pressed button X") seems forced and doesn't really work in multi-channel apps (let's say web apps and dialogue flows in chats).

In "traditional" applications with standard UIs, user actions like pressing a button results either in a direct service call or a directed async message. But what is the architectural pattern in a serverless setup, if we

  • don't know which function or service in my current setup is responsible for executing an action?
  • there are possibly multiple implementations and users should select the best candidate in a conversational UI? (the Android mechanism to handle intents, e.g. for opening a PDF and you have several viewers installed)

I am currently thinking about a (either configured or self-learning) component, which subscribes to user intents (with context) as broadcasted messages and is able to map them to actions (which once triggered start an event choreography). But maybe there are already proven frameworks or patterns I couldn't find because I am just not finding the right words.

Xogaz
  • 113
  • 1
  • 9
  • I'm not sure what you are asking, but you might be interested int the Whiteboard Pattern. It uses a service registry to decouple event sources from event consumers. See http://docs.osgi.org/whitepaper/whiteboard-pattern/020-background.html – ahoffer Oct 15 '21 at 21:25
  • Thanks.. Decoupling sources and consumers is (either OSGIs whiteboard pattern, event brokers or even more powerful systems like Google Pub/Sub) is certainly a must. But events are immutable things from the past, I wonder how we might apply the concept of event-driven architectures to pub/sub intendet actions (things we want to achieve in the future) – Xogaz Oct 19 '21 at 08:16

0 Answers0