View Models

View models provide a presentation layer on top of your content, allowing you to transform, compute, and aggregate data before returning it through the GCA. Unlike content models which expose raw content data, view models (classes extending ViewModel<M> with @ViewInterface) enable you to create computed fields, combine data from multiple sources, accept request parameters, and tailor responses to specific front-end requirements without modifying your underlying content types.

The GCA supports two ways to access view models:

Content-backed view models — accessed via the Get operation's View field when you have a content identifier. Ideal for transforming specific content items for presentation, with full support for editorial features like preview.

Standalone view models — backed by the endpoint itself and accessed via the root View field without requiring a content ID. Ideal for computed data like navigation menus, site configurations, or aggregated statistics.

Both access patterns produce the same kind of view types in the schema, detailed in the ViewModel Schema Types reference.

The examples in this section build on this configuration:

1
import java.util.Set;
2

3
import com.psddev.dari.db.Singleton;
4
import com.psddev.graphql.gca.GCAEndpoint;
5
import com.psddev.graphql.gca.GCASchemaSettings;
6
import com.psddev.graphql.gca.settings.OperationType;
7

8
public class ContentApiEndpoint extends GCAEndpoint implements Singleton {
9

10
    @Override
11
    public Set<String> getPaths() {
12
        return Set.of("/content-api");
13
    }
14

15
    @Override
16
    protected GCASchemaSettings getSchemaSettings() {
17
        return GCASchemaSettings.newBuilder()
18
            .readonlyEntryClass(Article.class)
19
            .entryViewClass(ArticleViewModel.class)
20
            .endpointViewType(OperationType.QUERY, NavigationViewModel.class)
21
            .build();
22
    }
23
}

Why view models?

If you're deciding between exposing content models directly versus through view models, see the discussion in Getting Started. In short: content models are great for ingestion, migration, and internal tools; view models give you a stable, curated contract for public content delivery with business logic centralized on the server.