Project Web Polling — Architecture and Implementation

> Project Web Polling > Architecture and Implementation

Implementation

• Sever built with Python/Flask.
• Client built with HTML/JavaScript/Svelte.

Messages / Events

1. [Operator] --> (Poll) --> [Server]

   • HTTP Post request
   • Sent when the operator starts a new poll
   • Will result in a NewPollEvent being sent to the clients
   • Payload: JSON {title:string, description:string, options: {option_id:string, label:string}[] }

2. [Server] --> (Poll) --> [Client]

   • SSE Stream
   • Type: NewPollEvent
   • Payload: same as in ‘Poll’ from Client-to-Server above

3. [Client] --> (Vote) --> [Server]

   • Basic Post request (has a RemoteAddr)
   • Payload: FormData

4. [Server] --> (VotingResult) --> [Client]

   • SSE Stream
   • Type: VotingResult
   • Payload: JSON {option_id:string|NULL, votes:number}[]
     • option_id is NULL when interim result is masked
     • votes number of votes *

       Ideas for Masking current vote counts

       The Problem

       When the server pushes a VotingResult for each Vote immediately, a user could effectively unmask the interim results by frequently changing her vote, and observe the changes in the interim result display.

       Possible solutions

       1. Debounce interim results. Collect all Votes as they come in. Only sent updates after some votes came in and/or a certain time has passed.
          This has the added benefit of reducing load in heavily used polls.

       2. Differential Privacy approach. Collect all Votes as they come in. Change all outgoing data by +/-10% or +/-2 Votes

          * before sending. This way, the effect of each data fetch outweighs

       the of a single Votes.