Home
Welcome to QView (Next Generation)! In this GH repo Wiki you will find the draft MVP (Minimum Viable Product) of QView. The anticipation is that QView will be able to be used for Q2028 - less than 3 years from now! The timeline is ambitious, but why have it any other way? All the more reason to move fast in bringing QView into reality.
For those familiar with current solutions, QView is intended to combine into one SaaS platform the functionality that is currently offered on NazQuizzing.org (Tournament posting + team, quizzer and equipment registration) and on QMServer (communication with QuizMachine clients as their centralized server).
With this being a MVP draft, there are still several conversations to be had about the design of QView. Whatever you see here, view it as mutable - not set in stone.
Expect great things and believe the best can be accomplished. Remember who you're doing this for: The quizzers. May we all come to know God better as our personal Lord and Savior and learn greater and greater depths of gratitude for his love and mercy shown to us that we might display a genuine faith to all people as a testimony of Jesus' love - especially for those who do not yet know God.
"Therefore, since we are surrounded by such a great cloud of witnesses, let us throw off everything that hinders and the sin that so easily entangles. And let us run with perseverance the race marked out for us, fixing our eyes on Jesus, the pioneer and perfecter of faith. For the joy set before him he endured the cross, scorning its shame, and sat down at the right hand of the throne of God. Consider him who endured such opposition from sinners, so that you will not grow weary and lose heart." - Hebrews 12:1-3 (NIV)
- Hosted via Docker containers (*plan is to use orchestration for service scheduling, with more app containers during peak demand and fewer during low demand)
- React + Vite frontend (using TypeScript + MaterialUI for styles)
- Rust backend (using Actix web server (website))
- PostgreSQL DB
- Redis caching
- ORM = diesel (documentation; the ubiquitous ORM of the Rust language)
- May or may not use the Tsync Rust library for syncing types across frontend and backend depending on maintenance requirements (*if it requires too much maintenance then may go with two separate yet similar type libraries which both reflect the domain of QView)
- Live stats available for public viewing every 2-3 seconds
- Foundational functionality of client-server architecture currently seen in QMserver when used with QuizMachine.
- It is planned that Tournament Directors will be able to use a Markdown editor for displaying Tournament information to public viewers in a clean and organized manner.
-
[New Functionality]: Add a UI dialog box in QuizMachine for receiving (from QView) & selecting the Tournament and Room that the QuizMachine client wants to operate for and as. When selecting the Room from the Rooms list for a Tournament, a status would be included indicating whether another QuizMachine client has already checked-in and claimed that Room (and if that Room claim by another QuizMachine client is incorrect then there is some conflict resolution process that would take place). These dependencies then would serve schedule data in the form of Game objects, each with their own unique ID, to the QuizMachine client for the full scheduled duration of the Tournament. During the scheduling phase, any change to the Games of certain Rooms by a administrator of the Tournament in QView would be pushed automatically to those checked-in QuizMachine clients. QuizMachine client would be able to be used across multiple Divisions as dictated by the schedule. During operation, QuizMachine would send QuizEvents to QView containing the exact Game ID (and perhaps also QuizEvent ID which it would assign incrementally) instead of needing to rely on TDRRI (which previously served as the compound key of Games and QuizEvents before switching to a 'centralized data with an authoritative server as the data owner' approach). There may still be some legitimacy in having a data validation backup where the Tournament ID, Division ID, Round ID and Room ID are sent in every QuizEvent from QuizMachine to QView in addition to the Game ID, however the Game ID would serve as the primary means for matching a QuizEvent to its Game in QView. (Time will tell if the Game ID is all that is needed after all.)
-
[Compatibility]: When using/connected to QView, no more assigning GUIDs (TDRRIs) to the client’s own Rounds. Require QuizMachine client to queries QView server to GET a RoundID for a new Round for purposes of reporting back and having an exact ID to map into the remaining data schema of QView when it reports Round Events.
-
[Modernize]: Potentially: Update Round Event endpoint on QuizMachine to use the modern REST POST method for reporting Round Event data, instead of using the current implementation of sending param values in the URL (less secure).
- In working toward accomplishing the performance goal of providing stats with very quick update cadence (every few seconds), the below diagram illustrates the process flow of a QuizEvent received from a QuizMachine client by QView:
