[yt314]

I counted the API calls the app makes on each screen load and per minute while idle. Two sources buy nothing.

1. The unread counters polled a tab nobody was looking at

The messages icon and the notifications bell each refresh once a minute. A plain timer keeps doing that in a background tab: a tab left open overnight sends hundreds of requests for a badge nobody can see, and on a phone it spends data and battery on the same.

Measured over 150 seconds with the tab reporting hidden:

before → polls while hidden: 4
after  → polls while hidden: 0

The timer now runs only while the tab is visible. It also fires the moment the tab comes back:

polls in the first 2.5s after coming back: 2  /api/messages/unread-count /api/notifications/unread-count

So the counter is actually fresher on return than the old timer left it — before, she could come back to a badge up to a minute stale.

2. GET /api/teachers/me three times per page load

### /app/dashboard — 13 API calls
    3× GET /api/teachers/me
### /app/lessons — 11 API calls
    3× GET /api/teachers/me

Three callers, same request, same answer, one page load:

caller	what it wanted
profileSetupGuard → ProfileSetupService.load()	isProfileComplete
TeacherShellComponent	fullName for the header
DashboardComponent → load() again	isProfileComplete, which the guard had just fetched

ProfileSetupService already documents the intent — "נשמר במטמון כאן ולא נשלף בכל ניווט" — but load() always hit the network, so the cache only ever helped the guard.

They now share one request, held in TeacherProfileService. Two things make it safe:

• Keyed by the signed-in account, not cleared on logout. Whoever signs in next gets their own profile even if the sign-out path never ran — there is no logout hook left to remember to wire this into. Verified by signing out and signing in as a different teacher in the same tab: the header read רחל כהן, not מרים לוי.
• Dropped whenever anything changes the profile (details, subjects, photo upload, photo delete), and dropped on a failed request so an error is never replayed to later callers as if it were the answer. Verified by editing a field, navigating away and back, and seeing the new value.

teachers/me requests on one dashboard load: 3 → 1

Result

/app/dashboard  13 → 11 API calls
/app/lessons    11 →  9
/app/students    6 →  5
/app/payments    7 →  6
/app/messages    5 →  4

Also checked — nothing to fix

• No N+1 in the controllers: the list endpoints each run exactly 1 SQL query (/api/lessons for a month, /api/students, /api/payments, /api/notifications, a student card), measured against the EF command log.
• The foreach loops flagged by a first scan in PaymentsController, StudentsController and TeachersController all await outside the loop — not N+1.

Testing

• npx ng build — clean.
• npx vitest run — 30 passing (app.spec.ts fails on main too, unrelated).
• Every number above was measured in the browser, before and after.

Demo data untouched — the one field edited to test cache invalidation was restored to קטמון and verified in the database.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
talmidon	Ready	Preview	Sep 18, 2026 8:58am UTC