Initial PR I imagined

[eppak]

@Bezkup I want to suggest some PR I can work on, here my list (with no particular order):

1. Containerization.
2. Bun as runtime.
3. Monorepo.
4. Vitest.

Let me know if for you are acceptable/interesting.
BR

[Bezkup]

Hey @eppak, thanks for the issue.
I agree with Vitest and Containerization. However what's the value of the other options?

• I'm not familiar with Bun, is it faster than Node?
• Do you mean creating two submodules, one for the client and one for the server?

[Pierpaolo1223]

@Bezkup I want to suggest some PR I can work on, here my list (with no particular order):

1. Containerization.
2. Bun as runtime.
3. Monorepo.
4. Vitest.

Let me know if for you are acceptable/interesting. BR

Adding to these proposals, I want to suggest some PR, here my list (with no particular order):

1. Git Conventions: Add a section in README.md to follow standard Git conventions for all version control procedures (branching, commits, and PRs). This ensures a clean, traceable history and smoother collaboration. Conventional Commits would be a great starting point.
2. Database Migrations: Introduce a migration tool to replace the current "Schema-on-Startup" logic. This is crucial for Containerization and future-proofing. We can finalize the specific tool (e.g., Drizzle, Kysely, or db-migrate) once we decide between Node and Bun.
3. User Roles & Ownership: Refactor the quiz logic to allow users to register and manage their own quizzes. This avoids the need to log in with a single shared admin account just to create or start specific quizzes, making the system much more flexible.

Let me know if these sound good to you!
BR

[eppak]

Hello @Bezkup, my responses:

Hey @eppak, thanks for the issue. I agree with Vitest and Containerization. However what's the value of the other options?

• I'm not familiar with Bun, is it faster than Node?
  Summarizing I can give you these insights:

• Speed, see the intro here (it says 4x faster than node): https://bun.com/
• All in one too, no need for package manager: https://bun.com/docs/pm/cli/add#bun-add
• Integrated, out of the box, TS support, no need for trans compiler, bundler etc: https://bun.com/docs/typescript#typescript

Compatible with 95% of node standard packages: https://bun.com/docs/runtime/nodejs-compat#node-js-compatibility.

• Do you mean creating two submodules, one for the client and one for the server?
  You already approached the structure of a mono-repo, so implementing it with a tool come into my mind because were a low hanging fruit. It help to manage the repo like orchestration along with the possibility to refer in a clean way to shared packages. The choice can be related to the one above because can be implemented in many ways, e.g.:

• Turbo.
• Pnpm workspaces.
• Bun workspaces.

For example if we decide that bun is a thing we can stay with the same tool and use its workspaces: https://bun.com/docs/pm/workspaces

Let me know.

[Bezkup]

@Pierpaolo1223 thanks for the suggestions!

Git Conventions: Add a section in README.md to follow standard Git conventions for all version control procedures (branching, commits, and PRs). This ensures a clean, traceable history and smoother collaboration. Conventional Commits would be a great starting point.

I'd like to put the git conventions inside a new file, maybe CONTRIBUTION.md?

Database Migrations: Introduce a migration tool to replace the current "Schema-on-Startup" logic. This is crucial for Containerization and future-proofing. We can finalize the specific tool (e.g., Drizzle, Kysely, or db-migrate) once we decide between Node and Bun.

I agree on the database tool. After seeing this thetutlage/meta#8, I'd tend towards Kysely, since it's type safe.

User Roles & Ownership: Refactor the quiz logic to allow users to register and manage their own quizzes. This avoids the need to log in with a single shared admin account just to create or start specific quizzes, making the system much more flexible.

I honestly don’t know. Let’s say users forget their password: what would they do?
Since setting an email is not allowed, their account would be lost and they would be forced to create a new one, as there is no password recovery.

This project is more of a one-shot quiz with a host and players; I wouldn’t see it as a “global” hub. That said, I’m open to reconsidering it 🙂

[Bezkup]

@eppak Ok, you sold me on it. Waiting for your PR 👍🏻

[Pierpaolo1223]

@Pierpaolo1223 thanks for the suggestions!

Git Conventions: Add a section in README.md to follow standard Git conventions for all version control procedures (branching, commits, and PRs). This ensures a clean, traceable history and smoother collaboration. Conventional Commits would be a great starting point.

I'd like to put the git conventions inside a new file, maybe CONTRIBUTION.md?

For me, it's ok, so on this file we can add other contribution policies.

I agree on the database tool. After seeing this thetutlage/meta#8, I'd tend towards Kysely, since it's type safe.

I could make a PoC,just for check if it works for our purposes (for now,only using the Node runtime)

I honestly don’t know. Let’s say users forget their password: what would they do? Since setting an email is not allowed, their account would be lost and they would be forced to create a new one, as there is no password recovery.

This project is more of a one-shot quiz with a host and players; I wouldn’t see it as a “global” hub. That said, I’m open to reconsidering it 🙂

It depends on how we decide to evolve the project. In the case that we decide to remain on a in-memory DB, we don't need the admin role, as seen as data are stored in our device, and we even remove the "admin" page. In the case that we decide to use DB like PostgreSQL or similar, an authentication and authorization should be mandatory in my opinion.

[eppak]

@Bezkup Quote accepted, preparing invoice 😂

[Bezkup]

in the case that we decide to remain on a in-memory DB, we don't need the admin role, as seen as data are stored in our device, and we even remove the "admin" page.

@Pierpaolo1223 if we remove the Admin page, how can an host start a game? Even if we use a in-memory DB, we must use the authentication/admin otherwise everyone could see everyone quizzes, and that would be a mess.
I'd rather keep SQLite. We don't need high performance (or advanced features), and thus SQLite it's the best choice IMHO.

I could make a PoC,just for check if it works for our purposes (for now,only using the Node runtime)

@eppak is preparing a PR for Bun, so I suggest you to make it with it :)

[Pierpaolo1223]

in the case that we decide to remain on a in-memory DB, we don't need the admin role, as seen as data are stored in our device, and we even remove the "admin" page.

@Pierpaolo1223 if we remove the Admin page, how can an host start a game? Even if we use a in-memory DB, we must use the authentication/admin otherwise everyone could see everyone quizzes, and that would be a mess. I'd rather keep SQLite. We don't need high performance (or advanced features), and thus SQLite it's the best choice IMHO.

Actually, there could be simple alternatives to a traditional admin role that would solve both problems:

For starting the game:

• The person who creates the room gets a "Start" button (no complex auth needed, just a simple flag in the room data) or auto-start when reaching X players or a countdown timer after the first player joins

For the "everyone could see everyone's quizzes" concern:
With an in-memory DB and room-based architecture, this isn't an issue because:

-Each quiz lives in its own isolated room/context
-Players only access it via invitation (code/link)
-There's no public feed listing all active quizzes

Data is ephemeral and tied to that specific game session

The UX would be almost the same: a user creates a quiz (no authentication needed), shares the code, invited players join, and the creator starts it. No one sees other quizzes because... there's no page that shows all quizzes! 😄

However, given the various concerns and different opinions that have emerged, I suggest we don't get too stuck on this decision right now. Let's keep things simple for the moment and focus on more critical aspects of the project. We can always revisit this later if needed.

I'd rather move forward and start with the PoC (but idk if I need to wait @eppak for runtime change). What do you think?