👨‍🏫 Week 1 of Building Edly: Schemas, Structure, and Smart Choices

Every big product starts with a small step — this week, I took mine.

Welcome to Week 1 of building Edly, a full-stack online course platform focused on giving educators their own branded subdomains (like anmol.edly.com) and complete autonomy over their content.

🚀 Introduction

As a passionate developer focused on solving real problems, I started building a full-stack scalable learning platform where educators can create their own branded subdomains, manage courses, and monetize their knowledge. The goal was simple:

Let any educator/creator launch their own mini version of Udemy — fully controlled, fully branded, and scalable — without the need to build a platform from scratch.

This series of blogs will be a full documentation of my technical journey: every decision I made, why I made it, what alternatives I considered, where I struggled, and what I learned.

🔧 The Problem I Wanted to Solve

Many educators want to build branded learning platforms with:

• Subdomains (e.g., anmol.edly.com)

• Control over content

• Built-in monetization

• Certificate issuing

• Analytics

But existing solutions like Udemy, etc., don't offer true autonomy. So I envisioned a centralized platform (like Shopify for learning) that gives individual educators their own admin control and learning environment under subdomains.

---

🧠 Phase 1: Architecting the System

I decided to start with the MERN stack:

• MongoDB: Flexible schema — perfect for course/content hierarchy.

• Express.js + Node.js: Lightweight and scalable backend.

• React.js (Coming soon): Dynamic UI for student and educator interfaces.

• Subdomains architecture: Each educator has a unique space like anmol.edly.com.

🧩 Why MongoDB?

• Schema flexibility: Each course has modules → modules have lessons/pdfs/quizzes.

• Easy to embed related structures or reference them for performance.

• Designed for read-heavy platforms with document-based content.

🗂 Deciding Between Monolith vs. Microservices

Although microservices seem attractive for scalability, I stuck with a monolithic architecture for Phase 1 due to:

• Faster iteration

• Easier debugging

• No infrastructure overhead

In the future, once I hit scale, I can break services like auth, content, and analytics into microservices.

---

🔐 Phase 2: Setting Up Educator Onboarding & Authentication

I started with the educator flow first:

• /register: Register an educator with a subdomain and basic profile.

• /login: Log in to access the dashboard.

• /onboarding: A simple form to collect organization details, bio, etc.

🧱 Educator Schema

const educatorSchema = new mongoose.Schema({
  firstName: String,
  lastName: String,
  emailId: { type: String, unique: true },
  password: String,
  subdomain: { type: String, unique: true },
  bio: String,
  organization: String,
});

I chose to assign a unique subdomain per educator. Later, this will help me configure dynamic routing or proxy setups for subdomains like anmol.edly.com.

🔐 Auth Controller

• JWT-based auth

• Middleware to attach req.user

• Only logged-in users can create courses, modules, content

---

📦 Phase 3: Designing Course → Module → Content Hierarchy

This was a major design decision. I explored multiple options and faced a few challenges:

Option 1: Nest Everything (Embed modules & lessons inside course)

✅ Simple, easy access
❌ Hard to update independently
❌ Inflexible for future analytics

Option 2: Normalize Everything (Separate models + references)

✅ Scalable
✅ Easily update lessons, modules
✅ Trackable analytics
✅ Works well with subdomain filtering

🧠 I chose Option 2. Here’s the architecture:

• Course: created by educator

• Module: belongs to a course

• Content: contains either a video lesson, PDF, or quiz

• Content items are referenced with a flexible field

---

🏗 Models I Created

📘 Course

title, description, thumbnail, price,
aboutCourse (6 paragraphs),
highlights (5 one-liners),
educatorId (ref)

📁 Module

title,
courseId (ref),
content: [ { type: 'lesson' | 'pdf' | 'quiz', refId } ],

📄 Content Models (Separate for clarity)

• Lesson:

  • title, videoUrl, moduleId

• PDF:

  • title, pdfUrl, moduleId

• Quiz:

  • title, questions[], moduleId

---

🔄 Controllers Created

• courseController.js

• moduleController.js

• lessonController.js

• pdfController.js

• quizController.js

Each one has:

• create

• delete

• For modules, an updateModuleContent to add new lessons/pdfs/quizzes in sequence

✅ Lesson of the Day: Maintain Sequence

I struggled a bit with how to store content in a proper order.

Solution: A content[] array inside Module with type + refId pattern. This lets me maintain the order as they were added by the educator.

---

🔍 Problem I Encountered

❓ “How will students know which courses they can access?”

✅ Solution: On course creation, I store educatorId → then during API calls, filter based on the logged-in educator.

❓ “How do I maintain modularity for updates?”

✅ Solution: Normalize everything. Independent models make it easy to update/delete without touching the parent document.

❓ “Should I use MongoDB’s default _id or custom IDs?”

✅ Used MongoDB’s _id — they’re unique, indexed, and scalable.

---

📊 Future Scope ( Coming Soon)

• Student flows: registration, enroll in course, access content

• Doubt engine: raise questions, educators reply

• Live class integration (e.g., Jitsi/Zoom APIs)

• Subdomain handling with reverse proxy (e.g., Nginx/Express middleware)

• Payment system: Stripe integration

• Certificate issuing engine

• Dashboards for educators: analytics, earnings, student behavior

---

📚 What I Learned

• Don’t over-engineer early — monolith was the right choice.

• MongoDB gives you enough flexibility but use references smartly.

• Auth flow is key to controlling access and visibility.

• Always think about "who can see/edit what?" while building APIs.

• Document your journey — helps you reflect, debug, and share.

---

✨ Final Thoughts

This journey is not just about building a project — it’s about design thinking, problem-solving, and developing a mindset for scale. By carefully choosing the right architecture and anticipating future needs, I’ve laid the foundation for a powerful learning platform.

I’ll be uploading a new blog every Wednesday as I continue building this platform, until the project is complete. Each post will dive deeper into key features, tech decisions, and lessons learned along the way.

If you're an aspiring full-stack developer — remember:

Start simple. Validate. Iterate. Scale.

---

🔗 Connect with Me

If you found this helpful or have feedback, connect with me on GitHub or Linkedin.

Stay tuned for the next blog — where I’ll build out the student-side APIs and begin rendering content dynamically via React. 🚀