Published in International Journal for Research in Applied Science & Engineering Technology (IJRASET), Volume 12 Issue III, March 2024. DOI: 10.22214/ijraset.2024.59296
Why I Wrote This
During my final year of undergrad, I wanted to build something that solved actual problems students face - scattered notes, no collaborative coding environment, and disconnected learning resources. LearnSpace was the answer. We turned the project into a published paper to document the architecture and development decisions behind it.
1. Problem
Traditional learning platforms lack integration. Students juggle between multiple tools for coding practice, note sharing, project collaboration, and accessing research papers. There's no single platform that brings all of this together in a cloud-native architecture.
Most college projects at the time were deployed on a single VPS or just run locally. We wanted to go further - build something production-grade, containerized, and deployed with proper CI/CD from the start.
2. Why Cloud Native?
Instead of just deploying to a single server, we followed cloud-native principles from day one.
Containerization
Every service runs in a Docker container, making it portable and consistent across environments.
Managed Services
Instead of self-managing databases and email servers, we used MongoDB Atlas, AWS S3, and AWS SES.
Automated Pipelines
No manual deployments. Every code push triggers a full build-test-deploy cycle.
Stateless Application Layer
The app server doesn't hold session state. JWT tokens handle authentication, so any container instance can serve any request.
A traditional VPS deployment would work for a college project, but it teaches you nothing about real-world infrastructure. Cloud-native forced us to think about deploying without downtime, scaling under load, managing secrets securely, and handling file uploads at scale. These are the same questions you face at any production company.
3. Solution - LearnSpace
We built LearnSpace using the MERN stack (MongoDB, Express.js, React.js, Node.js) with a three-tier architecture.
The Presentation Layer uses React.js with Tailwind CSS and Redux Toolkit for state management. The Application Layer runs Express.js and Node.js for authentication, API endpoints, and business logic. The Data Layer uses MongoDB Atlas as the cloud database with Mongoose for schema management.
Key Features
- Interactive Learning Paths - Curated roadmaps for structured learning
- Integrated Code Editor - Practice coding assignments directly on the platform
- Project Repository - Create and manage project repositories
- Academic Notes - Upload and share handwritten/digital notes
- Research Papers Database - Access and share research papers
- Role-Based Access - Admin, Faculty, and Student dashboards with JWT authentication
4. Cloud Architecture
The entire platform runs on AWS. Users hit the app through CloudFront for fast CDN delivery. Amazon ECS runs multiple Docker containers of the Node.js backend, load balanced across instances. MongoDB Atlas stores all user data, assignments, submissions, and metadata. S3 handles file uploads - avatars, PDF notes, project covers, and research papers. SES manages transactional emails like verification, notifications, and password resets.
5. Containerization
We containerized both the frontend and backend using Docker with multi-stage builds. The first stage installs dependencies (large layer, cached), and the second stage copies only production dependencies and source code. This keeps the final image smaller, faster to push to ECR, and more secure since dev dependencies are excluded.
The Docker images were pushed to Amazon ECR (Elastic Container Registry) and pulled by ECS for deployment.
6. CI/CD Pipeline
The full pipeline runs from code push to production automatically. When a developer pushes to GitHub, AWS CodePipeline picks up the change and triggers AWS CodeBuild. CodeBuild pulls the source, runs tests, builds the Docker image, and pushes it to Amazon ECR. ECS then pulls the new image, performs a rolling deployment (replacing containers one at a time for zero downtime), and runs health checks before shifting traffic.
Key decisions we made - rolling deployments so users never see downtime, automated testing before builds so broken code never reaches production, and environment variables managed through AWS Systems Manager Parameter Store instead of hardcoding them.
7. What I Learned
- Cloud-native from day one - Designing for containers and managed services from the start is fundamentally different from "lift and shift". It forces you to think about statelessness, service boundaries, and deployment automation early.
- Role-based auth is complex - JWT + role-based dashboards (Admin/Faculty/Student) taught me a lot about authorization flows and middleware design.
- AWS service integration - Wiring together S3, SES, ECS, and CodePipeline gave me hands-on experience with production AWS infrastructure.
- File uploads need a strategy - Direct uploads to S3 with pre-signed URLs are much better than routing files through your server. We learned this the hard way.
- Writing a research paper - Documenting architecture decisions formally made me think more critically about design choices.
8. If I Rebuilt This Today
Looking back with over a year of professional infrastructure experience, here's what I'd change:
- Kubernetes (AKS) over ECS - I now work with AKS daily. Kubernetes gives you more control over scheduling, networking, and scaling compared to ECS.
- Terraform for IaC - All infrastructure was set up manually through the AWS console. Today I'd define everything as code with Terraform.
- GitHub Actions over CodePipeline - Simpler, more flexible, and doesn't lock you into AWS. CodePipeline was overkill for our use case.
- PostgreSQL over MongoDB - For structured relational data like users, assignments, and submissions, PostgreSQL would have been a better fit. MongoDB made sense at the time because we were MERN-focused.
- Next.js over React SPA - Server-side rendering, API routes, and better SEO out of the box. The React SPA approach meant we needed a separate backend entirely.
- Redis for sessions - Instead of pure JWT, a hybrid approach with Redis-backed sessions would handle token revocation better.
9. Impact
This project directly shaped my career trajectory. Building and deploying LearnSpace on AWS was my first real exposure to cloud infrastructure, which led me toward the DevOps and infrastructure work I do today.
The paper itself was a bonus - it forced me to articulate technical decisions in a structured way, which is a skill I use every day when writing design docs and runbooks at work.
Citation:
- D. Murli Krishna Reddy, Shaik Ahmad Nawaz, Tammana Chandrika Naga Durga, Pillutla Surya, Shaik Sajid Ameer, "Design and Implementation of a Cloud Native Application for Collaborative Learning", IJRASET, Vol. 12, Issue III, March 2024.