search

drawr-org / drawrserver

0 stars 0 forks source link

Architecture considerations #13

Open robertgzr opened 7 years ago

robertgzr commented 7 years ago

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

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

robertgzr commented 7 years ago

/cc @pedroscaff @LukasJue

LukasJue commented 7 years ago

First of all, I think everything about management, where you don't draw, but need information about the session should be in the HTTP-API, and everything that is important to the users in real time or while drawing should belong to the websocket. I really would like, to keep that websocket-stream free of data, that could also be delivered asynchronously.

For your second point: I think we should keep it simple. I mean, your suggestions are good, but they would lose the scope of drawr. Let me explain that: we want an simple API so that everyone can make an application for drawr, and HTTP is supported by so many frameworks. If we use maybe advanced, but less supported, technology for our API, we increase the obstacles for beginners. I really would like to enlarge our API, instead of making it more efficient. But that's an tough decision... How big do you estimate the benefit from an RPC-Protocol? @robertgzr

For the messageformat I'm not sure... First of all, we want to send as less useless (and by useless i mean redundant) data as possible. So when a technology helps us, to reduce redundant information, I'm likely to support that. But on the other hand, every programming language that could be interesting for drawr has an JSON API. I can see, that Protobuf has a growing collection of supported languages, that cover most usecases I can think of, but I know there are usecases, I can't even think of. I don't want to reduce our potential.

robertgzr commented 7 years ago

  1. About the division between API and protocol: I agree. That would mean once we get to canvas annotations, the data attached to them would be queried via the API while we need to think of a way to communicate their position via websocket messages. The same goes for content rendered onto the canvas.

  2. I also lean more towards keeping it traditional with a HTTP-API, the main reason to switch to gRPC would be ease of development (because a lot of code can be generated from the protos). There is also https://github.com/grpc-ecosystem/grpc-gateway which means we could still offer both...

  3. Looking at the blog post I linked (their game's architecture is very similar to drawr):

    However it turned out that JSON is just too talkative and we send too much data over the network. The reason was that JSON is serialized to string representation that contains the whole schema, along with field names for every object. Moreover every value is also converted to string and therefore a simple 4 byte integer can become “2147483647” which is 10 bytes long (and it gets worse with floats). Since our simple approach assumed that we send the state of all spaceship to all clients it means that the server’s network traffic grew quadratically with the number of clients.

The only components involved with it are the server (Go) and the library (JS) (both of which have protobuf libraries). And even if it would be necessary Java and ObjC are supported as well.

And like for 2. using protobuf reduces the implementation overhead because we only need to work out a spec and can then just generate the interfaces.