Developer UX: Requiring SSL on first-time local setup sucks

[canadaduane]

In Braid, we depend on keep-alive streams to keep state up-to-date on the client. Unfortunately, however, HTTP1.1 supports a paltry 6 simultaneous streams. This means we are limited to 6 state resources on HTTP1.1 using the current spec.

Since HTTP2 supports multiplexing any number of streams, it's natural to reach for HTTP2 as the solution; however, HTTP2 requires SSL. Therefore, when running on localhost, HTTP2 adds an additional layer of friction to a first-time developer experimenting with Braid: they must install a self-signed certificate and click past the "scare screen" in the browser.

Possible solutions:

• Limit first-time demo apps to 6 state resources
• Braid over Websocket
• Multiplex resources over single stream
• others?

[canadaduane]

Possible implementation for multiplexing over single stream: https://docs.microsoft.com/en-us/graph/json-batching

[canadaduane]

Here's another possible solution:

• Change notification events: If a client could be notified whenever any resource has changed, then that client could request a regular HTTP GET (i.e. not keep-alive) on the changed resource.

Pros:

• compared to multiplexing, simpler implementation on the server side

Cons:

• slower & more request overhead

[toomim]

I like the approach of adding a WebSocket fallback to use in local development, and @brynbellomy and I have been sketching a protocol for that here: https://braid.org/protocol/websocket