Scaffold Application Server

[harveysanders]

We'll need to scaffold out an initial application server. Let's list/discuss the MVP specs here.

Routes

Frontend Static assets

• GET /
• Serves the assets (JS, HTML, CSS, etc) to run the frontend application

REST endpoints [TODO]

• Routes: [GET, POST, PUT, DELETE] /api/:apiVersion/:resource
• Any necessary CRUD operations
  • Creating a new Jam Session
  • TODO more resources

Websocket services

• GET ws://[appRoot]/ws

Jam Session MIDI communication

• GET /ws/jam/:sessionId
  This endpoint is used for transmitting MIDI and other Jam Session-specific messages between musicians

WebRTC Signalling Service

• GET /ws/signal/:sessionId
  This service handles signaling to initialize WebRTC connections between peers in a specific Jam Session

[adoublef]

looking at the scaffold branch, there is quite a lot of things going on, do we have a place that explains the decisions made and some of the files used? Just so its easier on people that are new or less experience with such tech

[pmoieni]

@adoublef those files are just some boilerplate code for the server. No worries I'll add some comments to describe the process better. It doesn't have anything to do with the main goal of the project.
And also don't mind the files inside ent folder. It's just a user database schema with some info about the user. Like email username and role.
It'll be used for authentication process and user sign up.

[adoublef]

As well documenting how the schema was generated. The ent directory seem to be all auto-gen files so knowing where those started from makes it clearer as to why that package was chosen

[hansvb]

For v0.0.1 I would propose to keep it extremely minimalistic:

• no sessions (just one big session)
• no database or users
• a /-route that serves as a kind of admin-page (showing all current connections and latencies) and with a JOIN-button that points to /jscli, hence this is also some kind of client but more focused on the overview
• a /jscli-route that serves a minimal browser-client where users can do something musical
• a /ws-route for our own rapidmidiex-ws-protocol

Thus only a websocket-based protocol v0.0.1 which can be upgraded later.

I wouldn't spend too much time on MIDI-compatibility for v0.0.1. Just a simple noteOn/noteOff in a json-websocket-text-message and some ping/pong (or similar) for latency-measurement. So a very minimal rapidmidiex-ws-protocol v0.0.1.

And maybe a few more different v0.0.1-clients as well.

┌─────────────────────┐
│                     │
│ rapidmidiex-tuicli  │
│       v0.0.1        │───────┐
│                     │       │
└─────────────────────┘       │
┌─────────────────────┐       │
│                     │       │
│ rapidmidiex-testcli │       │
│       v0.0.1        ├───────┤
│                     │       │
└─────────────────────┘       │        ┌──────────────────────────┐          ┌───────────────────┐
┌─────────────────────┐       │        │                          │          │                   │
│                     │       ├───────▶│ rapidmidiex-ws-protocol  │─────────▶│  rapidmidiex-srv  │
│  rapidmidiex-jscli  │       │        │          v0.0.1          │          │      v0.0.1       │
│       v0.0.1        │───────┤        │                          │          │                   │
│                     │       │        └──────────────────────────┘          └───────────────────┘
└─────────────────────┘       │
┌─────────────────────┐       │
│                     │       │
│ rapidmidiex-elmcli  │       │
│       v0.0.1        │───────┘
│                     │
└─────────────────────┘

[adoublef]

I presume admin page is only for us right?

[hansvb]

For v0.0.1 I wouldn't bother with a real admin-page (that can kick clients or whatever functionality that is supposed to have?). Just a general free-for-all-overview-start-page with some buttons for the different clients than can be used. And it would be nice to see who is already connected with what client and what latency and/or other stats like how long the client is already connected, how many notes have been played, ...

[adoublef]

ah that makes sense, could you explain what tui and elm are for? I presume terminal and Elm respectively right?

[hansvb]

For v0.0.1 I would propose to add as many client's as people want to work on. If a client is not ready, it can be moved to the next release?