/v1/users/me slow (~1.7s) — dominates authenticated cloud.near.ai load

[Evrard-Nil]

/v1/users/me is slow (~1.7s), dominates authenticated cloud.near.ai load

While verifying the cloud.near.ai slowness fixes (nearai/nearai-cloud-ui#221), /v1/users/me stands out as the slowest hot-path endpoint.

Measurements (from cloud.near.ai, Vercel function now colocated in pdx1 / US-West, same region as cloud-api)

Median of 5, via the proxy routes that call each endpoint:

cloud-api endpoint	via	median
/v1/users/me	/api/auth/admin (is-admin check)	~1728 ms (1722–3047)
/v1/organizations	/api/organization/list	~766 ms
/v1/.../invitations	/api/invitations/list	~573 ms

Same function, same region, same network path to cloud-api — so the ~2.5× gap is endpoint processing, not network.

Why it matters

/users/me returns the full AuthUserInfo graph (user + all organizations[] + all workspaces[]). The cloud UI calls it on every authenticated page:

• the is-admin check (useIsAdmin → /api/auth/admin → /users/me), and
• the client userInfo bootstrap.

So ~1.7s is on the critical path of essentially every dashboard navigation. In the cloud.near.ai dashboard trace it's now the single largest API cost (the UI-side fixes removed the duplicate org/workspace fetches and colocated the functions; this is what's left).

Note on a possible regression

In pre-fix traces ~18h earlier, the same /api/auth/admin path measured ~230–300 ms. It is now a stable ~1.7s. Worth checking whether a recent cloud-api change or data growth (org/workspace join fan-out) regressed /users/me.

Ask

• Profile /v1/users/me server-side (likely N+1 / unbounded join across orgs + workspaces + memberships).
• Consider trimming the payload or paginating the org/workspace arrays, or a lighter /users/me?fields=….

Related: #743 (identity/session separation), nearai/nearai-cloud-ui#221.