Smart Library Docs

Services

Backend service layer — business logic for email dispatch, user operations, and isolated concerns.

Services

The service layer (backend/src/services/) isolates business logic from HTTP controllers, promoting testability and separation of concerns.


1. Email Service

File: backend/src/services/emailService.js

A comprehensive transactional email service that dispatches formatted HTML emails for various system events using Nodemailer.

Core Function

sendEmail(to, subject, text, html)

The generic email dispatch function used by all other email helpers.

ParameterTypeDescription
tostringRecipient email address
subjectstringEmail subject line
textstringPlain-text fallback body
htmlstringRich HTML body (defaults to text if empty)

From Address: "SLMS Admin" <{SMTP_USER}> (or no-reply@slms.com)

Specialized Email Functions

FunctionTrigger EventParameters
sendWelcomeEmailNew user account createduserEmail, userName, tempPassword, role
sendPasswordResetPassword reset requesteduserEmail, userName, resetLink
sendBookIssuedNoticeBook checked outuserEmail, userName, bookTitle, dueDate
sendBookReturnedNoticeBook returneduserEmail, userName, bookTitle
sendOverdueNoticeBook is overdueuserEmail, userName, bookTitle, fineAmount
sendFineResolvedNoticeFine paid or waiveduserEmail, userName, amount, action

Error Handling

All email functions propagate errors via throw — callers should wrap in try/catch. Failed sends are logged to console.


2. User Service

File: backend/src/services/userService.js

A scaffold/prototype service layer for user business logic, demonstrating the service pattern.

Functions

createUser(userData)

Placeholder for user creation business logic (password hashing, DB insertion).

  • Returns: Mock user object with provided data

getUserById(id)

Placeholder for user retrieval logic.

  • Returns: Mock user object

Note: This is a prototype file establishing the service layer pattern. The actual user logic currently lives in controllers/userController.js.


Architecture Pattern

Controller (HTTP)           Service (Business Logic)
┌────────────────┐         ┌──────────────────────┐
│ Receives req   │────────▶│ Validates rules       │
│ Sends res      │◀────────│ Calls models          │
│                │         │ Calls external APIs    │
│                │         │ Returns data/errors    │
└────────────────┘         └──────────────────────┘

Benefits of This Pattern

  1. Testability — Services can be unit-tested without HTTP overhead
  2. Reusability — Multiple controllers/routes can call the same service
  3. Separation — HTTP concerns (status codes, headers) stay in controllers; business rules stay in services

On this page