proposal: custom-element as Rules engine
Opened this issue · 1 comments
Expose custom-element
with actionable components as Rules Engine to be run in the context of browser and on back-end.
MVP
Rule engines are used in applications to define some of the business logic declaratively in user-friendly manner.
In the web applications it is often used to guide the user across multiple microapplications. For example, drive the user UI for the 1st time login via legal compliance, basic user preferences, and the setup for chosen services. The Rules Engine
would trigger each sub-flow based on the user account properties.
Goal
Expose the custom-element
as the rules engine for the most popular scenarios. Demo the showcase as for browser-driven session as for back-end web service exposed to be consumed by web apps and other web services.
In technical terms, the goal is to provide the state change management framework which
- loads the default/initial/last state either from inline serialized or remote data
- loads the updated/runtime state
- on each state node chage trigger the rule-driven action component with preserving the updated(by trigger) state as "current"
The Rules Engine comprise:
- declarative conventions based on
custom-element
- web app and web service SDK
- UI designer. DnD graph editor.
- runtime state monitor UI in web and devtools for single "process"
- commercial dashboard for ^^ for multiple "process" correlation and analytics.
- commercial LM-driven designer and analytics board
references
Chllenges
- the rules engine meant to be driven in runtime-modified config, better via user-friendly UI( diagram, etc. ).
While thecustom-element
payload is available via loading in runtime viasrc
attribute, the additional security precautions need to be in place as in any web service APIs. Shouldcustom-element
has to extend thefetch-element
request properties?
Parts of rules engine SDK
- Visual editor
- CRUD web servive
- Browser Runtime. Hopefully fit into usual
custom-element
semantics and syntax. - Backend runtime.