Start new backend with stateful server and volatile state

[joshuaauerbachwatson]

This issue covers the greater role for the backend section of the README.

A possible sequence for implementing it is:

• [x] Implement a first-cut backend in TypeScript or Go based on App Platform examples. Authentication just with a private burned-in token (not committed to the repo).
• [x] Change the front end to use the new backend and eliminate the communicator abstraction. At this point, the game is only playable if you know the burned-in token.
• [ ] ~Add Auth0 hooks so that the game becomes more widely playable.~

At this point, the game would be as playable as it was before and just as restricted. After that, I would need to either add communication channels (so that players could discuss the game, enforce the rules, etc) or else add game rule sets which would be the subject of a new issue.

[joshuaauerbachwatson]

Some refinements:

1. The backend will be in golang. I've gotten a start on it.
2. The first cut will use basically the same protocol as the serverless version: with polling. The main difference will be the serverful dispatch and the use of in-memory volatile state in the server.
3. The token will not be burned in.
   • on the server side it will be read from the environment and will be an AP environment secret.
   • on the client side it will be stored after an initial "login" sequence. This dialog will be a temporary stand-in for the eventual auth0 login.
   • we can use this approach for quite a while before we would actually need to integrate auth0
4. Before actually integrating auth0, there are some things that should be done first because the way auth0 has to be integrated will likely be different, depending.
   • Switch from using http + JSON to using gRPC. There are implementations in both Swift and golang.
   • Ideally, fix the connection management so we can support gRPC in both directions or at least some one-way flows for multicasting new state, after which we can eliminate polling.
   • Use both the "subscriber" token (for game creation) and the "player" token (for playing existing games) in the "correct" way for gRPC (whatever that is). At that point, switching to auth0 really just comes down to how that bearer token is acquired.

Depending on how all this comes out, I might complete this issue and work on more substantive things before worrying overmuch about opening the game to the public (which is really where auth0 comes in).

[joshuaauerbachwatson]

The token will not be burned in. on the server side it will be read from the environment and will be an AP environment secret.

Yes.

on the client side it will be stored after an initial "login" sequence. This dialog will be a temporary stand-in for the eventual auth0 login.

No. I already have a Secrets.swift file on the client side that is not committed to the repo and this is fine for a temporary solution. It won't bother app platform because it is only looking in the backend folder and will ignore the client source area. As long as we use the approved AP approach for secrets management on the server side we are fine.

[joshuaauerbachwatson]

The server is now running with the proper secrets management and a number of code fixes that I discovered in testing.

The new implementation gets through game creation and joining a game with a valid token but the management of the player list is clearly wrong (over time, duplicate player names accumulate in the player lists).

[joshuaauerbachwatson]

I've reduced the scope of this issue so I can close it when the new server achieves rough parity to what the multicast peer implementation could do. All the follow-on steps will be new issues. I'm also making issues for sub-tasks (like fixing the player list management, issue #3).

[joshuaauerbachwatson]

The new backend is now working adequately and I have deleted the old one. Contrary to the original task outline, I am not removing proximity communication under this issue but rather closing it. The Communicator abstraction is still there and still has two embodiments. I'll create a new issue about deciding the fate multipeer communiction.