Currently, I am engaged in developing a TypeScript and GraphQL system in which certain GQL requests’ results can vary based on the user's level of permission within the system. To illustrate this concept, let's consider quotes and line items.
When a user requests to view a quote, it may contain a list of line items with information like price and quantity. However, access to the price details differs among users. Presently, we are handling this by allowing most fields to be nullable, but this approach has proven to be challenging and lacks accuracy in representing the system. Our goal is to utilize the TypeScript and GraphQL type systems more effectively and accurately reflect the system dynamics.
We are considering creating specific types to define the data that can be returned at each permission level. For example,
interface LineItemWithPricing {
id: string;
name: string;
description: string;
cost: number;
taxable: boolean;
quantity: number;
}
interface LineItemWithoutPricing {
id: string;
name: string;
description: string;
quantity: number;
}
... (more attributes exist for a line item and other field combinations are possible)
type LineItem = LineItemWithPricing | LineItemWithoutPricing | <other options>;
(I'm skipping over the potential use of Pick and Omit for brevity and clarity.)
The main query that arises is whether incorporating permission levels into the type system for systems where data values and API return types are affected by permissions is a viable option. Is there a standard method for representing this? Are there superior alternatives available?
We have begun implementing some of these type strategies, and it seems feasible to delineate our system using sets of types like this. The concern revolves around encountering maintenance challenges in the long term.