Understanding Before Building: My Deep Dive into RUXAILAB’s Architecture

Codebase Study — Learning the System Before Changing It

Before writing a single line of code, I made a conscious decision:
I wouldn’t treat RUXAILAB as just another repository to explore—I would treat it as a system to understand.

Because adding A/B testing is not a small feature. It touches everything—study flow, user interaction, data storage, and analytics. And if I didn’t understand those pieces deeply, any implementation I write would either be fragile or disconnected from how the platform actually works.

So I started from the ground up.

I traced how a study is created, how participants interact with it, and how their responses move through the system. Instead of reading files one by one, I focused on flow:

• How Vue modules manage state and drive the UI
• How Firebase (Firestore, Auth, Cloud Functions) handles data and logic
• How collections like tests, answers, and users interact
• How the platform maintains consistency across the entire lifecycle of a study

At some point, the codebase stopped feeling like scattered files and started feeling like a coherent pipeline.

That shift was important.

Because the real goal of this phase wasn’t just understanding—it was answering a much more critical question:

Where does A/B testing naturally belong in this system?

Through this exploration, I identified clear and practical integration points:

• The study workflow as the anchor for attaching experiments
• The router layer for triggering participant assignment
• Cloud Functions for deterministic, secure variant allocation
• Firestore as a scalable event logging layer for experiment metrics

These weren’t assumptions—they came from observing how the system already behaves and aligning with it.

This is exactly reflected in my proposal design, where the A/B testing layer integrates cleanly into the existing stack without disrupting current workflows .

What This Phase Really Means

This wasn’t just a “Completed” task on a list.

This was the phase where I:

• Built a mental model of the entire system
• Identified real integration constraints
• Started thinking in terms of implementation, not theory

I also went a step further—while studying, I began sketching early ideas for:

• Experiment schemas
• Deterministic assignment strategies
• Event logging pipelines

So this wasn’t passive learning. It was active system design thinking.

Why This Matters for the Project

A lot of contributions fail not because of poor coding—but because they don’t align with the architecture.

By investing deeply in this stage, I’ve reduced that risk significantly.

Now, when I move into implementation:

• I’m not guessing where things fit
• I’m not forcing new logic into the system
• I’m building in a way that is consistent, modular, and scalable

And most importantly, I can confidently say:

I understand how this system works—and I know how to extend it without breaking it.

Closing Thought

For me, this step reflects how I approach open source.

Not by rushing into contributions,
but by first understanding the intent behind the system—and then building in a way that respects and evolves it.

That’s what makes this project not just achievable for me, but something I can execute efficiently, cleanly, and at production quality.