Introduction
It's been a while since I kick-started my backend engineering journey, and the plan was simply to take each major concept in the backend landscape and learn it then learn one or two of its application like for example, learning about databases then learning PostreSQL & Mongodb, for more details checkout this blog article I wrote, which talks about this point in great details:
but essentially after a while, I realized that it's not the most optimum way to make it to the other side where senior backend engineers are! So let's discuss together why I'll switch to a more practical and hands-on learning approach and how I'll do it...
Limitation Of Previous Theoretical Learning Approach
First of all, backend engineering is simply building things! of course you need to learn the necessary tools and building blocks (web servers, protocols, proxies, ....) so you can build something with them in the first place! but for someone who already has put a foot in the software engineering world, its easier, funnier and more practical to learn by building projects rather than learning pure concepts that you already have at least a basic idea with, and can be further understood by utilizing them in a project you're building.
Second, in the realm of backend, some things aren't just learnable by taking courses or reading articles and documentation, things like architectural concepts like micro-services, webhooks or operational skills like CI/CD and project maintenance and a lot more, one of you may argue that there is plenty of courses, docs and articles that teaches those things in details, but for me such concepts are better learned by doing then use their learning resources as references, just like you do with cooking recipes you don't study the recipe a head of time then cook it later!, the same can be said about a lot of backend engineering knowledge:
Better learned by doing rather than reading
Finally and most important for me is me realizing that learning backend concepts piece by piece won't take you far, and that because those concepts are glued together in away that makes learning them separately doesn't make to much sense in the real world.
The Project We'll Build and It's Requirements
Choosing the right project to work on wasn't easy. I wanted something that's packed with features so I can utilize lots of different technologies and learn as much as possible. But most importantly, it had to be something I'm really passionate about and could work on for a long time.
My choices varied between:
- E-Commerce backend system
- Social Media backend system
- Blogging website backend system
- E-Learning platform or a Learning management system (LMS)
After weighing my options, I've decided to build a Learning Management System (LMS).
An LMS is a great project that will gimme room to implement a lot of core backend concepts: beside the obvious ones: Framework, Database, Authentication I can also implement a lot of other cool things like: splitting it into separate micro-services, implementing a messaging queue so the system is more robust and less coupled and a lot of other technical requirements.
The requirement of the (LMS) I wanna build are as follows:
1. User Roles
1.1 Teacher
- Can create, manage, and publish courses.
- Has access to a dashboard for course management and analytics.
1.2 Student
- Can enroll in courses, view course content, and track progress.
- Has access to a dashboard for viewing enrolled courses and progress.
2. Core Features
2.1 Course Management
- Teachers can create and manage courses, including adding modules, lessons, quizzes, and assignments.
- Course content can include text, images, videos, presentations, and other multimedia elements.
- Teachers can set prerequisites, deadlines, and grading criteria for courses.
2.2 Student Enrollment
- Students can browse the course marketplace and enroll in courses.
- Enrollment process includes payment integration for paid courses.
- Students receive notifications and updates on enrolled courses.
2.3 Dashboards
- Teacher Dashboard:
- Overview of course analytics, including enrollment, completion rates, and student performance.
- Tools for managing course content, assignments, and communication with students.
- Student Dashboard:
- List of enrolled courses with progress tracking.
- Access to course materials, assignments, and grades.
2.4 Communication
- Integrated messaging system for communication between teachers and students.
- Discussion forums for course-specific discussions and peer interaction.
- Announcements and notifications for important updates and deadlines.
2.5 Assessment and Grading
- Support for various assessment formats, including quizzes, assignments, and exams.
- Automatic grading for objective assessments and manual grading for subjective assessments.
- Gradebook for teachers to track student performance and provide feedback.
2.6 Course Marketplace
- Platform for course creators to publish and sell their courses.
- Course discovery features, including search, filters, and recommendations.
- Revenue sharing model for course creators and platform fees for transactions.
3. Technical Requirements
3.1 Frontend
which is the thing that it is not my priority for now, I'll focus on implementing a big part if not all the backend logic before I think of the front end
3.2 Backend
- Scalable and secure backend infrastructure hosted on cloud service.
- RESTful, gRPC, websockets, GraphQL APIs (maybe only restfull, maybe two of them maybe all I'm not sure yet) for communication between frontend and backend components.
- Micro-services architecture where each part of the bakcend system will have each own containerized independent service
- Integration with third party services (payment gateways and storage buckets, ...)
3.3 Database
- Relational database management system is must for such big system with tones of related entities.
- May NoSQL database for storing more instructed data like courses content and chapters......
- An in-memory data base for caching purposes.
4. Security and Compliance
4.1 User Authentication
- Secure authentication and authorization mechanisms for user accounts.
- Support for OAuth2 providers like google, github....
4.2 Data Protection
- Encryption of sensitive data in transit and at rest.
- Compliance with data protection regulations (e.g., GDPR, CCPA).
4.3 Access Control
- Role-based access control (RBAC) to restrict access to sensitive features and functionalities.
- Granular permissions management for admins, teachers, and students.
The Chosen Tech-stack and Why
Well well well, the choice of the tech stack will be highly subjective and constrained to the following 3 points:
Keep away from what I already know: where I'll try to get out of my comfort zone and use technologies that I'm not already familiar with (at the end of the day a lot of standardized technologies I'm not familiar with cuz I'm still kinda of a beginner)
Technology spread and popularity: This one is pretty straightforward, since I'm new and yet learning no need to choose some fancy rust based backend framework that only few hundred people know how to use on the world!
What I personally see sexy and hot: Cuz most of the time there is multiple choices that are very popular, and I'm not familiar with but I choose one over the other for no reason but cuz it sounds sexier!
therefor here is my tech-stack for this project:
Backend Framework:
- NestJS: Main backend framework, providing a modular and scalable architecture for building server-side applications with TypeScript.
Database:
- PostgreSQL: Main relational database management system (RDBMS) used for storing and managing structured data in the project.
Programming Language:
- TypeScript: Language of choice enforced by NestJS, offering strong typing and modern features for enhanced developer productivity and code maintainability.
Message Broker:
- RabbitMQ: Messaging broker utilized for asynchronous communication and event-driven architecture, facilitating scalable and decoupled backend services.
Cloud Hosting Provider:
- AWS (Amazon Web Services): Cloud infrastructure platform used for hosting, deploying, and scaling the project's backend services and resources.
Payment Integration:
- Stripe: Payment processing platform integrated into the project for handling online payments securely and efficiently.
Object Storage:
- Amazon S3 (Simple Storage Service): Scalable cloud storage solution employed for storing and retrieving large files and media assets in the project.
Caching:
- Redis: In-memory data store utilized for caching frequently accessed data and improving the performance and responsiveness of the application.
Containerization:
- Docker: Containerization platform employed for packaging the project's applications and dependencies into lightweight and portable containers.
Container Orchestration:
- Kubernetes (K8s): Container orchestration tool utilized for automating deployment, scaling, and management of containerized applications in a clustered environment.
And Who Knows What Else...
Conclusion
What I truly like about this new approach is that there is a lot of skills that I'll be forced to learn, things like Database Design, Operational skills like CI/CD and a lot more. And Concerning Java and DSA nothing changed, my DSA journey is still running and the next blog post will be either DSA Part 1 or Relational Database Design, so stay tuned and see yaaaaaaaaaaaaaaaaaaa
Top comments (2)
I guess you can skip the DSA part :) (I saw you already figured that out and started with the DB).
I think the problem when learning architectural concepts and especially "architectures" is that one might not see immediately (or even later on or after reading about) the "why". For example, why do we do microservices instead of doing a monolith? Why do we communicate asynchronously when direct, REST-style calls could do the job? And so on and so forth. And especially when one realizes the amount of effort hasn't really reduced, but it eventually shifted from app code to operations, and new "problems" like observability, for example, have to be dealt with.
So, I guess there should be a phase of acceptance, before true understanding settles in (and the latter can only come through experience) and a "lucky" match between initial assumptions on the project scale and chosen arch.
I also believe that architectures mostly respond to technical requirements, not to functional ones.
I'm hooked till the end