Optimise FE to remove N+1 calls to get project environments

[matthewelwell]

Currently when landing on https://app.flagsmith.com/organisation/:organisationId/projects, the FE iterates over all the projects and requests the environments for each one. For organisations with large numbers of projects this causes a performance overhead at the very least, and rate-limiting at the worst.

The FE should not need to get the environments at this point in the load of the dashboard. The reason that it retrieves them is to know where to route the user to when selecting a project since the next URL is built as https://app.flagsmith.com/project/:projectId/environment/:environmentKey/features (by accessing project.environments[0].api_key.

Some possible solutions to this issue:

1. The API returns an environments list in each Project object returned on /api/v1/projects. The environments list could include:
   a. The whole environment object
   b. A summary object including the id, api_key and name
   c. Just a list of strings giving the api_key attributes of the environments
2. The FE retrieves the environments when the user selects a project and then routes the user accordingly
3. The BE adds functionality to add a 'default_environment' attribute to the project which the FE can route to

Option (1) would likely be the easiest as it means no refactor on the FE. Option (3) is perhaps the cleanest, but opens the question about whether it would be better to store this preference per user, or maybe use something like last_environment_visited?

[afsuyadi]

Hi @matthewelwell , can I work on this issue?

[Asheesh7298]

I'd like to work on this. I've traced the code and have a clear plan.

Root cause

The N+1 lives in frontend/common/stores/organisation-store.js. After fetching the project list from GET /api/v1/projects/, the store runs a Promise.all loop firing one GET /api/v1/environments/?project=<id> per project. The only thing the FE needs from this is environments[0].api_key to build the routing URL in ProjectManageWidget.tsx.

Approach: Option 1b — embed environment summaries in the projects response

I'll add a lightweight EnvironmentSummarySerializer (fields: id, name, api_key) nested inside ProjectListSerializer, and add prefetch_related("environments") in ProjectViewSet.get_queryset when the action is list. This keeps the DB cost at 2 queries total (projects + one bulk environments fetch) regardless of project count.

On the frontend, the Promise.all loop gets removed entirely. ProjectManageWidget.tsx already reads environments[0].api_key off the project object, so it needs no changes — it'll just work once the data arrives from the right place.

I'm going with 1b over the other options because:

• 1a (full env objects) ships far more data than the FE needs here
• 1c (api_key strings only) works but loses name, which is useful once a project is loaded
• Option 2 (lazy fetch on click) introduces a loading delay on every project card click — worse UX
• Option 3 (default_environment on the project) is a bigger design question and out of scope for this fix

Files touched

• api/projects/serializers.py — add EnvironmentSummarySerializer, add environments field to ProjectListSerializer
• api/projects/views.py — add prefetch_related("environments") for list action
• frontend/common/stores/organisation-store.js — remove the Promise.all environment fetch loop
• api/tests/unit/projects/test_unit_projects_views.py — tests for embedded environments shape and query count regression

Will open a PR shortly unless there are concerns with this approach.