Skip to content
This repository was archived by the owner on Jul 16, 2019. It is now read-only.
This repository was archived by the owner on Jul 16, 2019. It is now read-only.

Architecture considerations #13

@robertgzr

Description

@robertgzr

Current master implementation

uses HTTP API calls for basic session interaction/management

  1. GET on /session/new returns a new session id
    • internally we generate a new ULID [code]
    • ... create a new entry in the session DB with ULID as the key [code]
    • ... use this ULID to refer to the session (also exposed to users) [code]
  2. GET on /session/<session_ulid>/ws to start websocket connection
    • ... upgrades the connection [code]
  3. From here all communication of canvas updates goes over the websocket connection
    • possible message formats (known to the server) are defined here

Questions

  • What parts of the communication belong to the API vs. our websocket message protocol?
  • Non-websocket communication: HTTP-API vs. gRPC?
  • websocket message format: JSON (text-based) vs. Protobuf (binary)? Other options?

http://blog.u2i.com/we-made-a-multiplayer-browser-game-in-go-for-fun/

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions