Building a production-ready API from scratch is a rite of passage for every backend engineer. For my AltSchool Africa exam, I spent the last week building Yarncom — a secure, community-driven blogging engine.
Here is a breakdown of the architecture, the logic, and the environment "ghosts" I had to bust to get to a green terminal.
1. The Architecture: MVC and State Logic
To keep the system maintainable, I implemented a strict Model-View-Controller (MVC) pattern.
Models: Defined with Mongoose to handle complex schemas, including an Author reference that links Blogs to Users.
Controllers: The "brains" of the engine, managing the data flow and handling asynchronous handshakes with MongoDB.
State Machine: Articles transition between
draftandpublishedstates. I implemented security guards to ensure drafts remain private while published content hits the public feed.
Automation with Mongoose Hooks
One of the most satisfying features was building an automated Reading Time Algorithm. Using a Mongoose pre-save hook, the engine analyzes the word count of the body text and calculates the estimate before the document is even saved:
blogSchema.pre('save', async function() {
if (this.body) {
const wordsPerMinute = 200;
const words = this.body.split(/\s+/).length;
this.reading_time = Math.ceil(words / wordsPerMinute);
}
});
2. Stateless Security with JWT
I moved away from traditional sessions for this build, opting for JSON Web Tokens (JWT) stored in HTTP-only cookies.
This setup provides a stateless authentication layer that is both secure and scalable. The middleware checks for the token on every protected route, verifying the digital signature against a hidden JWT_SECRET before allowing the request to proceed to the controller.
3. Troubleshooting the "Ghosts"
In the journey to production, I encountered two specific bottlenecks that taught me more about systems than any documentation could:
The AirPlay Port Conflict (Port 5000)
I spent considerable time debugging a persistent 404 error where my server appeared to be running, but Postman couldn't find my routes.
The Discovery: macOS Monterey uses Port 5000 for the AirPlay Receiver.
The Fix: Migrating the local environment to Port 3000 resolved the conflict instantly.
Testing Isolation (Duplicate Keys)
While writing automated tests with Jest, I hit E11000 duplicate key errors.
-
The Fix: I implemented "Unique Data Assets" for the test suite, using timestamps (
Date.now()) for user emails to ensure every test run had a clean, isolated database timeline.
4. Quality Assurance: 22 Integration Tests
I didn't consider the project finished until the logic was bulletproof. Using Jest and Supertest, I wrote a comprehensive suite of 22 tests covering:
Auth handshakes (Signup/Login/Logout).
Search and Regex accuracy.
Authorization checks (Ensuring User B cannot delete User A's work).
Read-count incrementation metrics.
5. Live Deployment
The final build is officially live on Render, connected to a MongoDB Atlas cluster.
Links:
GitHub Repository: Yarncom github repository
Live Demo: Yarncom demo
Conclusion
This project wasn't just about passing an exam; it was about mastering Systems Design and Environment Awareness. Building Yarncom proved that a robust backend isn't just written but built through persistence and rigorous testing.
Onward to the next build!
Top comments (0)