Félix Malfait
f869ce87b1
## Experiment — not for merge as-is A perf experiment for discussion. Opening as a draft to gather feedback and let CI run. ## Problem On a warm (returning) load, the app gate ([`MinimalMetadataGater`](https://github.com/twentyhq/twenty/blob/main/packages/twenty-front/src/modules/metadata-store/components/MinimalMetadataGater.tsx)) blocks first paint until **both** object/view metadata **and** `currentUser` are ready. The metadata store is already cache-first: it persists each entity (including `status: 'up-to-date'`) to `localStorage` with `getOnInit`, opens from cache, and revalidates in the background via collection hashes. 👏 `currentUser` (and `currentWorkspace` / `currentWorkspaceMember` / `currentUserWorkspace`) is **not** — it lives in an in-memory atom, so every load fires a blocking `GetCurrentUser` round-trip before the gate opens. That round-trip is the one remaining network hop on the warm-load critical path; everything else the first screen needs is already in `localStorage`. ## Approach Generalize the pattern the metadata store already proves out, to the user bootstrap — **without adding any new `useEffect`**: - Persist the four bootstrap atoms (`currentUser`, `currentWorkspace`, `currentWorkspaceMember`, `currentUserWorkspace`) via the existing `createAtomState({ useLocalStorage, localStorageOptions: { getOnInit: true } })`. - The gate opens from cache on its own: the existing `IsMinimalMetadataReadyEffect` already derives readiness from the `currentUser` atom alongside metadata status, so persisting the atoms is enough — no new effect. - Keep firing `GetCurrentUser` (now `network-only`, no longer skipped when a user is present) so it **revalidates in the background** and the existing write-through effect updates the atoms with the fresh result. - Clear the cached identity on sign-out by adding the four keys to `clearSessionLocalStorageKeys` (already invoked by `clearSession`, which then hard-reloads). Net effect: warm loads no longer wait on `GetCurrentUser`; the shell paints from cache and corrects within one round-trip. Cold loads (no cache) are unchanged. ## Risks to validate - **Permission staleness** — `currentUserWorkspace` carries `objectsPermissions` / `permissionFlags`. Cache-first means a brief stale-permission window before revalidation. Not a security boundary (the server authorizes every request), but it can momentarily show a menu item the user no longer has; worst case it 401s and corrects on the next paint. - **Feature-flag / workspace staleness** — `currentWorkspace.featureFlags` may be one round-trip stale on warm load. - **`X-Schema-Version` header** — sourced from `currentWorkspace.metadataVersion`; caching it actually makes the header *consistent* with the already-cached metadata rather than absent, but worth confirming against the server's mismatch handling. - **Test isolation** — these atoms now persist; tests relying on the default `null` could see cross-test leakage if `localStorage` isn't reset. The directly-affected suites pass locally (`useAuth`, `useDefaultHomePagePath`, `useSetNextOnboardingStatus`); CI's full run is the real check. ## Validation - [ ] Full CI (types/lint/unit) green - [ ] Manual: throttle network, hard-reload a logged-in workspace, confirm the shell paints before `GetCurrentUser` resolves and that fresh data writes through - [ ] Sign out → sign in as a different user on the same browser; confirm no stale identity flashes
The #1 Open-Source CRM
Website · 
Documentation · 
Roadmap · 
Discord · 
Figma
Why Twenty
Twenty gives technical teams the building blocks for a custom CRM that meets complex business needs and quickly adapts as the business evolves. Twenty is the CRM you build, ship, and version like the rest of your stack.
Learn more about why we built Twenty
Installation
Cloud
The fastest way to get started. Sign up at twenty.com and spin up a workspace in under a minute, with no infrastructure to manage and always up to date.
Build an app
Scaffold a new app with the Twenty CLI:
npx create-twenty-app my-app
Define objects, fields, and views as code:
import { defineObject, FieldType } from 'twenty-sdk/define';
export default defineObject({
nameSingular: 'deal',
namePlural: 'deals',
labelSingular: 'Deal',
labelPlural: 'Deals',
fields: [
{ name: 'name', label: 'Name', type: FieldType.TEXT },
{ name: 'amount', label: 'Amount', type: FieldType.CURRENCY },
{ name: 'closeDate', label: 'Close Date', type: FieldType.DATE_TIME },
],
});
Then ship it to your workspace:
npx twenty app:publish --private
See the app development guide for objects, views, agents, and logic functions.
Self-hosting
Run Twenty on your own infrastructure with Docker Compose, or contribute locally via the local setup guide.
Everything you need
Twenty gives you the building blocks of a modern CRM (objects, views, workflows, and agents) and lets you extend them as code. Here's a tour of what's in the box.
Want to go deeper? Read the 
User Guide for product walkthroughs, or the Documentation for developer reference.
|
|
|
|
|
|
Learn more about version control in docStack
TypeScript
Nx
NestJS, with BullMQ, 
PostgreSQL, 
Redis
React, with Jotai, Linaria and Lingui
Thanks
Thanks to these amazing services that we use and recommend for code review (Greptile), catching bugs (Sentry) and translating (Crowdin).
Join the Community
Star the repo · Discord · 
Feature requests · Releases · 
X · 
LinkedIn · 
Crowdin · 
Contribute