When I started exploring RUXAILAB, my goal was not just to understand how the platform works, but to figure out how a new system—A/B testing—could be integrated without disrupting its existing workflow.
Instead of approaching the repository as a collection of files, I treated it as a system. I focused on understanding how data flows through the platform, how different layers communicate, and where extensibility points exist.
Understanding the Core Workflow
The first step was to map the lifecycle of a study inside RUXAILAB.
From my analysis, the workflow can be summarized as:
- A researcher creates a study
- Participants interact with the study interface
- Responses are stored in Firestore
- Analytics are generated based on collected data
This flow is already well-structured and modular. What stood out to me was that RUXAILAB is not just a frontend-heavy application—it is a coordinated system involving Vue modules, Firebase services, and backend logic working together.
Understanding this flow was critical because A/B testing is not a standalone feature—it needs to plug directly into this lifecycle.
Exploring the Architecture
RUXAILAB follows a clean separation of concerns:
- Frontend (Vue 3 + Vuex): Handles UI, state management, and user interaction
- Backend (Firebase): Manages authentication, Firestore data, and Cloud Functions
- Analysis Layer (Python): Processes data for insights
This layered architecture (also described in the proposal’s system design on page 5 ) makes the system highly extensible.
Rather than modifying existing components, new functionality can be introduced as a separate module that integrates with these layers.
Identifying Integration Points
A key part of my study was identifying where A/B testing naturally fits into the system.
I found three critical integration points:
1. Study Entry (Router Layer)
When a participant enters a study, this is the ideal moment to assign them to a variant.
This aligns with the existing router-based flow described in the proposal (page 9), where logic can be injected without affecting UI components.
2. Data Layer (Firestore)
The existing collections such as:
testsanswersusers
can be extended with an experiments collection (as proposed on page 6 ).
This allows experiment data to coexist with current study data without breaking compatibility.
3. Interaction Layer (Event Logging)
User interactions during studies already generate meaningful data.
By introducing an event logging system:
- task completion
- time on task
- error count
these interactions can be reused as experiment metrics without redesigning the data model.
Key Insight: Modular Extension Over Modification
One of the most important realizations during this study was:
The best way to integrate A/B testing into RUXAILAB is not by changing the existing system, but by extending it.
This aligns directly with the architecture goal:
- keep the current workflow intact
- introduce experimentation as a modular layer
- reuse existing data pipelines
Challenges While Studying the Codebase
While exploring the repository, I encountered a few practical challenges:
- Understanding how Vuex modules interact across features
- Tracing Firestore data flow between frontend and backend
- Identifying where business logic resides (frontend vs Cloud Functions)
To overcome this, I:
- followed data instead of files
- traced end-to-end flows instead of isolated components
- mapped interactions between frontend, backend, and database
This approach made it easier to understand not just what the code does, but why it is structured that way.
From Understanding to Implementation
This codebase study was not just theoretical.
It directly influenced how I designed and implemented the A/B testing prototype:
- Created a modular
experimentsfeature - Used Cloud Functions for deterministic assignment
- Designed Firestore schema aligned with existing collections
- Integrated event logging into study interactions
Because of this groundwork, the prototype fits naturally into RUXAILAB’s architecture instead of feeling like an external addition.
Final Thoughts
Studying the RUXAILAB codebase gave me a clear understanding of how a real-world UX research platform is structured and how new features can be introduced without breaking existing systems.
More importantly, it helped me move from:
- reading code → to reasoning about systems
- understanding features → to designing integrations
This experience gave me confidence that I can not only implement the A/B testing framework, but do so in a way that aligns with RUXAILAB’s architecture, maintains code quality, and supports future extensibility.
Top comments (0)