EduNexus

EduNexus is an institute management platform spanning attendance, fees and finance, exams and results, timetables, transport, hostel, library, inventory, HR and payroll, complaints and messaging. It is included here not for its feature count but for its engineering shape: a modular Express service with more than forty domain controllers, background queues, realtime and push delivery, sixteen integration test suites running against an in-memory database, and continuous integration that builds the frontend and runs the backend suite on every push.

Institutions run on a patchwork of spreadsheets, paper registers and messaging groups. The data exists but is not connected, so every question that crosses two domains — has this student's fee cleared before results are released? — becomes manual work.

The engineering problem is harder than the domain problem. A system like this has many roles with genuinely different views of the same records, work that must not happen inside a request (statement generation, bulk exports, monthly billing), and information that has to reach people who are not currently looking at the application.

Administrative software is judged on trust rather than features. If a fee ledger disagrees with a receipt, or an attendance record silently changes, adoption stops immediately and does not restart.

That pushes the engineering priorities somewhere specific: validated inputs at the boundary, authorisation that is enforced centrally rather than per handler, and a test suite that can prove the money-and-records paths still behave after a change.

The API is decomposed by domain — attendance, fees, exams, results, timetables, transport, hostel, library, inventory, HR, complaints, messaging — with each domain owning its controller, routes and models. Cross-cutting concerns live in middleware rather than being repeated per route.

Requests are validated with Joi before reaching a controller, sanitised against operator injection, rate limited, and passed through JWT authentication and role middleware. A handler can assume its input is well-formed and its caller is authorised.

Anything slow or scheduled is moved off the request path onto Bull queues backed by Redis: exports, document generation, notification fan-out, and a monthly fee scheduler that bills on its own clock rather than on a user's click.

Delivery is two-tier. Socket.IO pushes to connected clients; Firebase Cloud Messaging reaches people who are not. Email uses a single shared mail service so every module sends through one configured transport instead of each inventing its own.

Sixteen integration suites exercise auth, attendance, fees, exams, results, salary, staff attendance, timetables, transport, homework, complaints, notification attachments, CSV export and report-card export. They run against mongodb-memory-server, so the suite needs no external database and behaves identically on a laptop and in CI.

GitHub Actions runs two jobs on every push and pull request: a frontend production build and the backend test suite with --runInBand. A change that breaks either is visible before it is merged rather than after it is deployed.

A pre-start integrity check runs before both dev and start, so the process refuses to boot in a misconfigured state instead of failing later in a way that is harder to diagnose.

Data migrations and seeds are explicit, versioned scripts — demo seeding, username backfill, transport and timetable model migrations — rather than ad-hoc database edits.