Containers and views

A container is the physical storage of data. Think of them as tables in an SQL database, with properties as columns, indexes, and constraints on the data. Data is always stored in containers.

A view is the implementation of a type in the GraphQL specification. A view groups properties from one or more containers into a single interface. You can assign new names to the properties, implement another view and apply filters to only find subsets of the data.

This approach promotes designing data models with reusable containers, while you can use views to make them appear as if they were modelled together.

Sample data model

The examples below illustrate how you can reuse the views across data models and the containers and views the created by this data model:

datamodel.graphql

type Person {
  name: String!
  age: Int
}

type Movie {
  name: String!
  description: String
  watchedIt: Boolean
  imdbRating: Float
  releasedYear: Int
  gross: Int
  runTime: Int
  director: Person
  actors: [Person]
}

The data model creates two containers and two views. Both the containers and the views are named Person and Movie.

The containers and edges define the storage structure for the two types in the data model.

Person

Person view

View details	Value
externalId	Person
space	MovieDM
version	1
Properties
name	Person.name
age	Person.age

Person container

Container details	Value
externalId	Person
space	MovieDM
Properties
name	text (not null)
age	int64

Movie

Movie view

View details	Value
externalId	Movie
space	MovieDM
version	1
Properties
name	Movie.name
description	Movie.description
watchedIt	Movie.watchedIt
imdbRating	Movie.imdbRating
releasedYear	Movie.releasedYear
gross	Movie.gross
runTime	Movie.runTime
director	Movie.director
age	Movie.age
actors	Connection (MovieDM, Movie.actors, OUTWARDS)

Movie container

Container details	Value
externalId	Movie
space	MovieDM
Properties
name	text (not nullable)
description	text (nullable)
watchedIt	boolean (nullable)
imdbRating	float64 (nullable)
releasedYear	int64 (nullable)
gross	int64 (nullable)
runTime	int64 (nullable)
director	direct relation (Person, nullable)

This illustrates a simple mapping from the views to corresponding storage in containers.

Key insights

1. This seems complex, do I have to do this?

By default, when using the GraphQL data modeling language, for each data type a container and a view will be created for you unless you choose to use an existing view, or to map properties to existing containers.

You can also use the various additional directives to help you define more specific behaviors without having to worry about keeping track of views and containers.

2. Renaming when mapping properties

You can rename the properties, for example to use rating instead of imdbRating, and point to the imdbRating property in the Movie container.

3. Relationships

The actors connection is an extra property that act as a relationship in the view. Connections document the types of edges you expect to appear as actors in the Movie data type. You would need to populate the edges data separately from the nodes.

However, notice that director, while also a relationship, is a direct relation. This means a single direction 1 to 1 relation from Movie to Person. This method, while more limited in use case, provides drastically better performance.