Consolidate /app and /app/features endpoints
Experience has taught us that the client needs the session data (current user, list of groups) and set of enabled feature flags at the same time, and also needs to invalidate them in the same scenarios (eg. account switching). Fetching this data via two separate requests made it more complicated to ensure the client had a consistent view of session and feature-flag data. To simplify things and also same a network request: * On the server, put the feature flag data into the session data payload. * On the client, use the existing central storage and cache management for the session data payload to manage feature flags as well. The features service now becomes a thin wrapper around part of the session state.
Showing
Please register or sign in to comment