Server-driven UI schema design

Use enums, contracts, and interfaces to implement SDUI

💡 TIP

If you're an enterprise customer looking for more material on this topic, try the Enterprise best practices: Schema design course on Odyssey.

Not an enterprise customer? Learn about GraphOS for Enterprise.

These patterns provide examples of server-driven UI (SDUI) and how to structure your graph's schema to encode and represent UI elements. Clients can then use platform-specific rendering engines to interpret the schema and generate UI components.

💡 TIP

For more information on SDUI in general, see Server-driven UI basics.

Device-based SDUI with enums

Different devices (for example, mobile, web, Roku, Apple TV) may require different UI layouts or components. You can use enums for device type lists to declare which UI type to retrieve.

1
enum UIDeviceType {
2
  MOBILE
3
  WEB
4
  ROKU
5
  APPLETV
6
}
7

8
interface UIApp {}
9

10
type WebApp implements UIApp {}
11
type IOSApp implements UIApp {}
12
type AndroidApp implements UIApp {}
13
type AppleTVApp implements UIApp {}
14
type RokuApp implements UIApp {}
15

16
type Query {
17
  app(type: UIDeviceType! = WEB): UIApp!
18
}

In this example, the UIDeviceType enum lets you specify the type of device you want to retrieve the UIApp for.

Device-based SDUI with contracts

You can use a similar device-based SDUI with contracts to remove UI components that are unrelated to the target platform from your schema.

1
type UIApp {
2
  spotlight: UISpotlightComponent @tag(name: "DESKTOP")
3
  dashboard: UIDashboardComponent
4
  mobileMenu: UIMenuComponent @tag(name: "MOBILE")
5
  menu: UIMenuComponent @tag(name: "WEB")
6
}
7

8
type Query {
9
  app: UIApp!
10
}

💡 TIP

SDUI web dashboard

The following example shows a schema with a static structure that clients can use to create a web dashboard UI.

1
type AppLogo {
2
  url: String
3
  alt: String
4
}
5

6
type AppLink {
7
  icon: String
8
  label: String
9
  path: String
10
}
11

12
type AppUserMenu {
13
  user: User
14
}
15

16
type AppNavbar {
17
  logo: AppLogo
18
  items: [AppLink]
19
  user: AppUserMenu
20
}
21

22
type AppMobileMenu {
23
  items: [AppLink]
24
  user: AppUserMenu
25
}
26

27
type AppHomePage {
28
  recommended: [AppLink]
29
}
30

31
type WebApp {
32
  navbar: AppNavbar
33
  menu: AppMobileMenu
34
  home: AppHomePage
35
  settings: AppSettingsPage
36
  profile: AppProfilePage
37
}
38

39
type Query {
40
  app: WebApp!
41
}

SDUI web dashboard using interfaces

The example schema below is also for a web dashboard UI, but it uses interfaces to construct dynamic responses for the UI. By using interfaces, an "experience" subgraph can dynamically return different UI components.

1
interface UIComponent {
2
  id: ID
3
}
4

5
type UILogo implements UIComponent {
6
  id: ID
7
  url: String
8
  alt: String
9
}
10

11
interface UINavbarItem implements UIComponent {
12
  id: ID
13
  label: String
14
  path: String
15
  icon: String
16
}
17

18
interface UINavbar implements UIComponent {
19
  id: ID
20
  logo: UILogo
21
  items: [UINavbarItem]
22
}
23

24
interface UIMenuItem implements UIComponent {
25
  id: ID
26
  label: String
27
  path: String
28
  icon: String
29
}
30

31
interface UIMenu implements UIComponent {
32
  id: ID
33
  logo: UILogo
34
  items: [UIMenuItem]
35
}
36

37
interface UISidebar implements UIComponent {
38
  id: ID
39
  title: String
40
  content: [UIComponent]
41
}
42

43
interface UILayout implements UIComponent {
44
  id: ID
45
  content: [UIComponent]
46
}
47

48
interface UIScreen implements UIComponent {
49
  id: ID
50
  current: UIPage
51
  navbar: UINavbar
52
  menu: UIMenu
53
  main: UILayout
54
  sidebar: UISidebar
55
}
56

57
enum UIPage {
58
  HOME
59
  DASHBOARD
60
  SETTINGS
61
}
62

63
type Query {
64
  app(page: UIPage!): UIScreen!
65
}

Home