Local Service Runner with CLI

[CallmeT-ty]

• [ ] Let's create builder studio repo that contains the following underneath

CLI utiltity vs. Dev Service to run the reactor. A light version wrapper similar to switchboard.

Notes from initial conversation

'Dev service with local reactor, listening for changes, triggering a command/action'. Daemon would provide an API, seperate project that wraps the document drive and can connect to the CLI. Q: What is the main communication mode between the dev service, connect & CLI?

Synch browser local env. & connect? => Service would need a graphql interface. Websocket with seperate way?

Filesystem storage: Storing files in configured storage. CLI utility to be seen as a client. Look in the local folder. .PHD folder (initialised powerhouse environment) Configuration should have the port number it's running or assume the default. It tries to connect to the port number, verifies reactor is running. Waits for replies and shuts down.

This comes down to: A 'service runner': Connect service + reactor. User would use one terminal for cli, logs, output of codegen, which redirect you to use the connect ui. It has a graphql websocket interface that hosts the backend reactor powerhouse-inc/powerhouse#291 + connect front end service. powerhouse-inc/connect#557 CLI will detect that back end service is running and connect to that.

1) it's a package you can install and you can run. npm install ph-dev This will install the Local service runner and local CLI ph-dev ph-cli @powerhousedao/cli @powerhousedao/service-runner Both are dependencies of the the ph-dev package 2) npx ph init which will create the .ph folder 3) npx ph dev This would run the service runner with the reactor backend and connect front end service.

Service Runner

DoD $ npm install ph-dev $ npx ph init $ npx ph dev

Ability to run the three commands above and the service runner runs \ Reactor BE service \ Connect FE service which need to communicate with one another.

[CallmeT-ty]

@CallmeT-ty to add wireframes

[acaldas]

// reactor service accepts document drive as argument and returns express server // it's a express app // wraps document-drive with Graphql API

// switchboard // 1 init cache and db // 2 create document drive server // 3 call ReactorService(server) which returns an express server; // 4 wraps reactor service api with auth api

// CLI service runner // init connect studio // 1 memory cache + filesystem db (pgqlite in the future) // 2 create document drive server // 3 call ReactorService(server); // 4 add listener + trigger for connect studio // 5 add internal listener to auto-generate document models

• Frank

  1. rebase with main (format and lint rules)
  2. move subgraph to reactor-service (express app)
  3. move drizzle to document-drive storage adapter
  4. improve internal listener support in document-drive

• acaldas

  1. init reactor-service package (init document drive) set up ts, bundler, dev, and document drive import.
  2. add listener + trigger for connect studio
  3. add internal listener to auto-generate document models

Backlog:

• add websocket listener
• use reactor-service in switchboard (re-use express app with auth middleware?)
• drizzle storage adapter
  • optimistic concurrency control (version field on sync unit table)
• export read model from document-model-libs