Demo-app-take2

[ScottyPoi]

First draft of new demo app built on trpc.
zero-frills react app. meant for testing and demonstration of content lookups.
underlying trpc structure will be reusable interface for future app development.
the react package itself does not require portalnetwork or @chainsafe as dependencies, avoiding the need for webpack / browserify / etc.

The diagram below shows the flow for two different setups.

1. "Ultralight Max"

• tRPC Router instantiates an Ultralight client.
• tRPC Router uses Typescript to directly access Ultralight client.
• Queries/Mutations are processed directly
• Websocket server enables Subscriptions
  • optional
  • currently hardcoded into server script

2. "Client Agnostic"

• you have a PortalNetwork client running locally
• tRPC router serves as middleware between JSON-RPC and App
• App makes QUERIES/MUTATION calls to tRPC server.
• tRPC makes JSON-RPC calls to Ultralight
• Subscriptions are not possible
  • (without additional websocket setup)

3. "Ultralight Light"

• (not pictured)
• Run the "Ultralight" setup without the Websocket server.
• This would work identically, with the exception of Subscriptions, which would not be available.

4. "Client Specific"

• (not pictured)
• (not attempted)
• Run the "Client Agnostic" setup with an additional Websocket Server.
  • Would require some sort of interface to turn trin / fluffy traffic into nodejs events
    • entirely possible that this is entirely impossible 🤷

Ultralight Browser app serving 2 local clients

flowchart BT
    Browser
    subgraph C[ultralight/packages/client]
        direction BT 
        AppServer
            subgraph REACT
            direction BT
            State
            APP[Components]
            TYPE[tRPC_schema]
            TYPE --> APP
            TYPE --> State
            end
        REACT --> |npm run dev| AppServer
    end
    subgraph CLI
        direction BT
        subgraph HTTP[JSON RPC SERVER]
            direction BT
            C1{ANY PORTAL CLIENT}
            http[RPC Middleware]
            C1 --> http
        end
        subgraph SERVE[tRPC SERVER]
            direction BT
            trpc[trpc_router]
            router[trpc_server]
            websocket --> |SUBSCRIPTIONS| trpc
            C2 <--> |QUERIES/\nMUTATIONS| trpc
        subgraph WSS
            websocket[websocket_server]
            direction BT
            C2{ULTRALIGHT\nPORTAL CLIENT}
            C2 --> |EVENTS| websocket
         HTTP_SERVER_B[HTTP_SERVER: 8546] --> C2
        end
        end
        HTTP --> HTTP_SERVER_A[HTTP_SERVER: 8545]
    end
    HTTP_SERVER_A <--> trpc
    AppServer --> Browser
    trpc <--> router
    router <--> TYPE
    NETWORK((NETWORK))
    NETWORK <--> HTTP_SERVER_B
    NETWORK <--> HTTP_SERVER_A

Loading

tRPC Router contains the schema and logic for the tRPC endpoints.

The tRPC Router that is defined in the trpc server.ts script contains the actual logic for responding to queries/mutations/subscriptions from the trpc server. The router processes the tRPC calls from the App, and interacts with the Portal Client either directly, or using JSON-RPC.

Another version of the same schema exists in the React code.
This is in place simply to inform the App Components of the input / output types for the methods. It contains no actual logic, and does not actually get accessed.

The WebSocket setup is currently baked into the server.ts script

From ultralight/packages/CLI run npm run server:dev to start the client, wss, and trpc server.

To also run with HTTP only clients -- start clients using the npm run start -- or by using the devnet script.

At time of writing, the app is hardwired to expect an HTTP client at 8545 and a WSS client at 8546
User input of address/port has not been built

To start the APP:
from ultralight/packages/client run npm run dev

[acolytec3]

Just to make sure I'm tracking here, this jettisons the idea of running a client in browser, right? This is more a web app that interacts with a server where the server is a client running locally?

[ScottyPoi]

Just to make sure I'm tracking here, this jettisons the idea of running a client in browser, right? This is more a web app that interacts with a server where the server is a client running locally?

less a jettison of the browser client and more a new browser tool for interacting with a CLI client and/or local test network.
part of the point is that it could host ultralight, trin, or fluffy, and allow for some quicker debugging than just using hive

[acolytec3]

LGTM