Day 28 of #100DaysOfCode — Building a Library API

Today marks Day 28 of my #100DaysOfCode journey, and this session felt extra special. After learning the fundamentals, including Node.js, Express.js, REST APIs, middleware patterns, routing strategies, and working with request data, I combined these concepts to build a backend for a simple Library Management System.

---

Why a Library Management System Backend?

I chose to build a Library Management System backend because it’s the perfect balance between simplicity and real-world complexity. It touches almost every core concept of backend development, such as:

• CRUD operations
• validation
• authentication-like checks
• structured routing.

This library system has the following logics:

• Managing book details (title, author, genre)
• Managing library members (details of the members).
• Borrowing details of the members
• Availability of books
• Editing the details of books and members with a valid authentication token

---

📁 Folder Structure

library-api/
│
├── data/
│   ├── books.data.json
│   ├── members.data.json
│   └── borrows.data.json
│
├── routes/
│   ├── books.routes.js
│   ├── members.routs.js
│   └── borrows.routs.js
│
├── middleware/
│   ├── logger.middleware.js
│   ├── auth.middleware.js
│   ├── checkBook.middleware.js
│   ├── checkBorrow.middleware.js
│   ├── validateBook.middlewarejs
│   └── validateMember.middlewarejs
│
├── controllers/
│   ├── books.controller.js
│   ├── members.controller.js
│   └── borrows.controller.js
│
├── app.js
└── package.json

Structuring like this keeps the project clean, modular, and easy to expand.

---

🔄 Understanding the Flow of the Program

The API works through a clear and predictable request life-cycle:

1. Incoming Request → Middleware
   Every request first passes through the global logger middleware. The logger middleware logs the time of accessing an endpoint along with the URL and the method of accessing it

2. Route Matching
   Depending on the endpoint hit (/books, /members, /borrow), Express forwards the request to the corresponding route file.

3. Middleware Chains per Route
   Some routes require authentication, such as editing the details of a book or editing the details of the members. These middlewares run before the controller handles the final logic.

4. Controller Execution
   Each controller processes business logic:
   * Book controller manages CRUD operations for books
   * Member controller handles member records
   * Borrow controller manages issuing/returning books

5. In-Memory Data Files
   Instead of a database, the system uses temporary data files inside the /data folder. This helps simulate real database interactions while keeping things simple.

6. Structured Response
   Finally, a clean JSON response is sent back to the client, ensuring the API behaves like a real production-style service.

---

Final Result

Simple GET Request to get the details of the books

---

GET Request to get the details of one book

---

POST Request to add new book (requires authorization token)

---

Access member details (requires authorization token)

---

Access borrow details (requires authorization token)

---

Adding new member (requires authorization token)

---

🎉 Wrapping Up Day 28

Today’s progress was a huge confidence booster. Turning concepts into a real backend project helped solidify my understanding of Express architecture, routing patterns, and middleware logic. This Library API will serve as a strong foundation for more advanced topics like integrating databases, building authentication systems, and deploying to the cloud.

Happy coding (and building)! 🚀