Skip to main content

Backend modules, realtime, and notifications

The Academia backend is not one generic API surface. The frontend depends on several business modules, and some of the most important product behavior now comes from realtime updates, push delivery, and workflow-triggered notification services.

Why this page matters​

The main environment and API guide lists endpoint families, but contributors still need a clearer mental model of which backend areas exist and why the frontend feels event-driven in several flows.

Fastest route through this guide​

  1. Read Main backend service families to understand the module map.
  2. Read Workflow-driven notification model to see how product events reach users.
  3. Read Realtime channels to understand chat and live-update behavior.
  4. Continue to Announcements, notifications, and communication if you want the product-facing interpretation.

Main backend service families​

The current product already points to several core module families:

  • auth
  • admin
  • invitations
  • tenant
  • project
  • analytics
  • contact
  • notification
  • department
  • milestone
  • student-profile
  • group-leader-request
  • project-group
  • chat
  • evaluation
  • public

These names matter because they mirror the real business areas the frontend calls or depends on.

How contributors should use this module map​

The cleanest reading is:

  • use auth, tenant, and public when the feature is about entry, identity, or public forms
  • use project, milestone, evaluation, and analytics when the feature is about academic workflow
  • use notification and chat when the feature is about delivery of events or direct communication
  • use department, invitations, and admin when the feature is about governance and rollout control

Workflow-driven notification model​

The backend already emits workflow-sensitive notifications for real academic state changes.

Current documented examples include:

  • proposal submission notifications
  • proposal approval and rejection notifications
  • group-review notifications
  • milestone progress or approval notifications
  • evaluator reminder and late-stage follow-up behavior

This matters because the frontend is not polling blindly for every change. Several UI updates depend on backend event delivery or notification records.

Push-oriented delivery​

The current notification family also already includes push-oriented support.

Known examples include:

  • GET /notifications/push/vapid-public-key
  • push subscription endpoints under /notifications/push

This is the backend layer that lets the product move beyond in-tab awareness when the deployment model supports push delivery.

Realtime channels​

The frontend already derives a socket origin from NEXT_PUBLIC_API_BASE_URL for live integrations.

Current documented examples include:

  • notifications socket integration
  • chat socket integration

These channels authenticate with:

  • accessToken
  • tenantDomain

That keeps socket traffic aligned with the same tenant-aware trust model used by the REST client.

Why chat and notification modules matter together​

Chat and notifications are related but different.

  • notifications deliver workflow events and attention signals
  • chat supports direct conversation or contextual collaboration

The frontend needs both because a milestone approval, a proposal rejection, and a direct advisor-student conversation are not the same product event.

Practical contributor guidance​

When documenting or integrating a feature:

  1. identify which backend module family owns the business rule
  2. decide whether the feature needs REST only, realtime, or both
  3. keep tenant context consistent across Axios and socket connections
  4. document workflow events as part of the feature contract, not as optional UI decoration

Common mistakes to avoid in the docs​

  • Do not describe the backend as one flat API. Module boundaries matter for understanding behavior.
  • Do not document notifications as frontend-only toasts. They come from backend workflow services.
  • Do not forget push and socket behavior when explaining event-heavy features.
  • Do not separate realtime auth from normal tenant-aware auth. They share the same trust context.

Best page after this one​

If you want to do next...Go hereWhy
See the client-side integration rulesEnvironment and API clientIt explains how the frontend connects to these backend areas.
See the product-facing meaning of notifications and messagesAnnouncements, notifications, and communicationIt turns these technical layers into workflow language.
See host and tenant isolation behaviorMulti-tenancyIt covers the tenant-aware constraints that apply across these modules.

Best next reads​