Let's discuss the split of the editor and the runtime!
The WIP spec is in the github wiki: Editor Runtime API
As of late April 2018 there's also a runtime-api branch for the work in the repo.
And here's a quick quote of my "imagining a possible future" post from slack on April 13, 2018:
- editor which is a front-end-only app, running in a user’s browser
- an express-based REST API (editor/admin/runtime/whatever) running on a remote cloud server machine that the editor uses to get all the dynamic info it needs and to which the editor saves, deploys, etc.
- a headless runtime, on a separate cloud server machine, whose job is solely to run flows, (including accepting flow inputs and emitting flow outputs)
- I imagine the editor having no direct interaction with the runtime. Any such interaction, like showing live flow outputs, would pass through the API, for example editor opening websocket to API, API subscribing to events from runtime and passing received events out the websocket.
- the API would need storage, and the runtime would need storage, but ideally those could be separate. Any info they need to share, like deploying updates to flows, should use whatever we define as the interface between the API and the runtime.
- the interface between the API and the runtime should be customizeable — I was thinking that the existing storage API provides a good example — if we primarily define the interface as javascript methods, clearly defining the calls each side needs to make, the info each side needs from the other, then different companies could write custom implementations of such an API to fit everybody’s unique
architecture
And finally, to kick off this thread, a screenshot of an awesome update in slack from @knolleary as of April 24:
Discuss!
