Proposal: Scalable Architecture Strategy (Dev vs. Prod) & UI Standards

[CodeByRachit]

Hi @pradeeban @mdxabu

Regarding the recent feedback about the missing base structure and the directive to "work on code":
I have been analyzing the project's requirements for the upcoming GSoC period. My current PRs (Beehive 2.0 & UI Overhaul) propose a specific architectural foundation, and I want to ensure this aligns with your long-term vision before I optimize further.

1. Database Strategy (DX vs. Production) I implemented the current prototype using Flask + SQLite. I chose SQLite strictly to prioritize Developer Experience (DX)—ensuring the project remains "installable from a single command" for new contributors without complex setup. However, given the system's requirements, I assume the production target will likely be PostgreSQL for data integrity.

Proposal: I can refactor the backend to strictly use an ORM (SQLAlchemy) that supports a "Dual-Database" strategy: using SQLite for local development (speed/ease) and PostgreSQL for production (reliability).

Question: Does this approach align with your scalability plans, or do you have a different stack preference (e.g., Django)?

2. UI/UX Standardization I introduced the "Glassmorphism" design system and "Glider" navigation to set a consistent visual standard.
   Proposal: If this design language is approved, I can focus on documenting the CSS variables and component structure now. This would effectively create a "Design System" for other GSoC students to reuse, preventing UI fragmentation as the project grows.
   I am eager to finalize these foundational choices (Stack & Design) so the codebase is robust and ready for rapid feature development during the coding period.

Looking forward to your guidance!

[pradeeban]

@CodeByRachit various approaches are possible. Please make sure to explain and justify your approach in your proposal itself. Especially for a new project such as BHV, this is critical.

[CodeByRachit]

@pradeeban Understood Sir. Thank you for the clarification.
I will proceed with the Flask + Dual-Database strategy (SQLite for Dev, PostgreSQL for Prod) as my primary recommendation. I will ensure my final proposal includes a detailed technical justification section, specifically analyzing the trade-offs of this approach versus other stacks to demonstrate why it provides the best balance of maintainability and scalability for Beehive 2.0.
I will continue refining the current PRs to serve as a practical Proof of Concept for this architecture.

[pradeeban]

Awesome! Thanks.

[CodeByRachit]

@pradeeban Following your advice to justify the project's approach, I’ve evolved the architecture to a FastAPI + MongoDB stack. This shift (partially implemented in PR #94) specifically solves for 64KB chunked streaming and fault-tolerant sync, which I found critical for clinical resilience.The draft isn't final, but I believe the core architecture is now solid. May I send the PDF for your review?

[pradeeban]

@CodeByRachit sure. Pls cc the listed mentors of the project idea to a single email with your proposal draft.

[CodeByRachit]

@pradeeban Done! I've sent the email to you and the other mentors with the draft attached. Thank you for the opportunity

[CodeByRachit]

@pradeeban @mdxabu Could you please confirm whether the project size (Small, Medium, or Large) is predefined or determined based on the contributor?

[pradeeban]

The proposed size is mostly just a recommendation. Feel free to reduce the size, if you can deliver the expectations faster (90 or 175 hours instead of 350; 90 hours instead of 175). If you are increasing a "small" project into a "medium" or "large" or a "medium" project into a "large" one, you should justify with additional (code) deliverables.

[CodeByRachit]

Thank you for the clarification, @pradeeban That makes perfect sense. I will make sure my timeline and deliverables strictly justify the project size I select in the final proposal.

[CodeByRachit]

Hi @pradeeban and @mdxabu , I've updated my proposal to fully incorporate the self-contained local API Gateway/JWT approach we discussed—would you mind doing a quick final review before the deadline. May I send the PDF for your review?

[pradeeban]

@CodeByRachit Please upload the final PDF to the GSoC Portal on time. We will get back to you if we have comments or questions, by mid April.

[CodeByRachit]

Sure @pradeeban

[CodeByRachit]

@pradeeban @mdxabu I have uploaded my GSOC proposal