[skip/server] Split control service and streaming service.

[beauby]

This commit changes the REST API of the skip server, making it listen on two separate ports, one for the public facing streaming API, and one for the backend-only control API (sync reads/writes and stream creation/deletion).

The control API (by default exposed on port 8081) is now:

• GET /v1/resources/:resource: Sync read of a whole resource.
• GET /v1/resources/:resource/:key: Sync read of a single key from a resource.
• PATCH /v1/inputs/:collection: Partial write (update only the specified keys) of an input collection.
• PUT /v1/inputs/:collection/:key: Update of a single key of an input collection.
• POST /v1/streams: Instantiate a resource using the provided resource and params parameters (as a JSON object in the body), and return an UUID to subscribe to updates.
• DELETE /v1/streams/:uuid: Destroy a resource instance.

The streaming API (by default exposed on port 8080) is now:

• GET /v1/streams/:uuid: SSE endpoint to subscribe to updates of the resource instance represented by the UUID.

Splitting the two has several benefits:

• Avoiding the foot-gun of mistakenly exposing control routes to the outside world.
• Making it easier to support a redirection-based mechanism where clients connect directly to the streaming endpoint (vs deploying a more complicated infra to efficiently stream the updates directly through the web server).
• Not per se about splitting the APIs, but having an explicit stream instantiation endpoint allows for explicit stream destruction (for terminating currently subscribed streams of malicious actors identified by an external mechanism for instance).

[beauby]

I don't understand the description regarding "public facing streaming API" versus "backend-only control API". User clients will need to use both in order to set up, pull from, and close a stream, right?

No, only the streaming endpoint will be exposed to the outside world. The resource instantiation (POST /v1/streams) itself will be handled by the web app (by making a call to the control API on the backend's local network), and responding to the client with a redirect to the streaming endpoint.

Basically you can see the control API as analogous to a Postgres database connection, in that it is never exposed to the outside world directly.

It is "public-facing" versus "backend-only" that is confusing me. Any hints?

Does the above help?