We will need to build the reactor and storage adapters as separate components which switchboard integrates. Has to be easy to take a reactor, configure it with storage adapters and wire your api to it. This hard requirements makes it a lot less defining which framework to use for the back end api. (e.g. Modular approach)
Get the internals of reactor right > move as much switchboard code into the reactor & storage adaptor. Switchboard becomes a host that wraps around this setup.
Reactor architecture includes the listener infrastructure aswel. e.g. easy to configure reactor, define a bunch of listeners, use it in switchboard or connect environment.
Read models will become configurable reactor components (plugins) that support single or multiple environments.
Analytics engine should be able to support multiple environments. e.g. analytics in connect about your local connect data storage.
Search index read model that will be needed in multiple environments. e.g. search the content of your local documents in your local connect environment
Operational data models like the prisma model maybe more environment dependent e.g. unclear if we can run a relational database within connects web version. We do need a relational database read model.
We should focus our reactor and storage adaptors first before moving to different graphQL architectures.