Skip to content
Agile Defense

Curriculum / Frontend & OSDK Developer

INTERMEDIATEUnit 3unit-03

Build the React SPA on the Ontology

not started~300 min
Build a running React SPA that authenticates and renders a live object list/table from the Ontology via the OSDK.

Introduction

Scenario: The mission command app needs a usable front door: a running React single-page app that signs the user in and renders a live shipment object set from the supply-chain Ontology. You will bootstrap that SPA from the Developer Console default template and wire it to the OSDK package you already generated.

This unit turns the Developer Console application and generated OSDK package from the previous units into a real, running React single-page application (SPA) on the supply-chain Ontology. Developer Console lets you build customizable React user interfaces powered by the OSDK while treating Foundry as the backend. You enable a client-facing application, select Create code repository to bootstrap the default React template (already integrated with the OAuth2 authorization client and the Ontology SDK), and choose Open in VS Code to launch an in-platform Code Workspace with automatic environment setup and live access to Foundry resources. The SPA you build here authenticates the signed-in user and renders an object set—late shipments—drawn directly from the Ontology through the OSDK client.

An honest word on what can and cannot be verified for you, because it shapes how this unit is graded. The deliverable is client-side code: the code repository contents, the generated OSDK package, your React components, the OAuth2 client wiring, and the VS Code workspace all live in your development environment, and none of them are exposed by any documented Foundry READ API. Those facts are attested by you and reviewed by an instructor. What an automated check can confirm is the Ontology the app consumes—specifically that the late-shipment object set the list view depends on actually exists and is non-empty, reproduced through a read-only Aggregate Objects call. That single instance check is the difference between 'the UI is blank because of a code bug' and 'the UI is blank because there is no data', and it is the only part of this unit a machine can confirm. The rest is yours to attest honestly.

By the end you will have a SPA that passes its repository checks (npm run lint, npm run test, npm run build) and renders a live Shipment table that updates when the underlying Ontology data changes. Because this cohort can code, the unit assumes fluency with TypeScript/React and the OAuth2 redirect flow the template configures; the focus is on wiring the OSDK client correctly and reading from the Ontology, not on teaching React from scratch.

Capability focus: OSDK React applications; the default React template + code repository; auth-wired live object rendering. · Artifact: A running React SPA that authenticates and renders a live Ontology object set.

Key concepts

  • OSDK (Ontology SDK): A type-safe SDK that gives a development environment direct access to the Foundry Ontology; for this unit it is the generated TypeScript/NPM package the React app imports to read object sets. The OSDK client uses a token scoped only to the ontological entities the application is allowed to access, combined with the signed-in user's own permissions (least-privilege, governance-aware).
  • Developer Console: The tool used to build and manage Custom Applications and their associated authorization (OAuth) clients and SDKs. It is where you enable the client-facing application, Create code repository to bootstrap the default React template (wired to authorization + the Ontology SDK), and Open in VS Code. Application internals (repo, OAuth client config) are configured here, not exposed by an Ontology READ API.
  • VS Code workspace: An in-platform development environment deployed on Palantir infrastructure (Code Workspaces) for production-ready code including OSDK React applications, with automatic environment setup and integration with Foundry resources. This is distinct from the local Palantir extension for VS Code (covered in a later unit); the workspace and its contents are a dev-environment artifact, not a read-API surface.
  • Aggregate Objects (Ontology REST API v2): A read-only operation, POST /api/v2/ontologies/{ontology}/objects/{objectType}/aggregate, that computes count/sum/avg/min/max with optional where filters and grouping, requiring the api:ontologies-read OAuth2 scope. This unit uses a count aggregation over Shipment where status is late to confirm the object set the SPA renders is non-empty.
  • Search Objects (Ontology REST API v2): A read operation, POST /api/v2/ontologies/{ontology}/objects/{objectType}/search, that filters objects by a query in the request body and requires the api:ontologies-read scope. It is the read primitive the OSDK exposes (as list/where) when the SPA fetches the object set to render; it is detailed further in the REST API unit.
  • OAuth2 grant types: Foundry supports the Authorization Code Grant (acts on behalf of the signed-in Foundry user via redirect, issuing short-lived access tokens) and the Client Credentials Grant (non-interactive service user). A user-facing SPA uses the Authorization Code Grant; the default React template wires this flow, and the client config itself is set in Developer Console and is not read-API-exposed.

Companion video

OSDK React SPA walkthrough (placeholder) · open on YouTube

Hands-on activity

each step validates · the unit completes when all steps pass
  1. 1

    Create a code repository from the default React template and open VS Code

    MANUAL / self-attested. In Developer Console, enable the client-facing application, select Create code repository to bootstrap the default React template—already integrated with the OAuth2 authorization client and the Ontology SDK—and choose Open in VS Code to launch the in-platform Code Workspace with automatic environment setup. This is the manual, attested foundation of the unit: the repository contents, the generated OSDK package wiring, and the VS Code workspace are client-side / dev-environment artifacts, and no documented Foundry READ API can introspect them, so you attest that they exist and an instructor reviews them. Record the application name, the repository, and that the workspace opened with the OSDK dependency installed.

    not startedself-attested

    Self-attested: a code repository is created from the React template (wired to auth + OSDK).

  2. 2

    Confirm the object set the SPA will render is non-empty

    INSTANCE / read-confirmable. Before trusting the UI, confirm the data it depends on actually exists by reproducing the SPA's list view through a read-only aggregation: Aggregate Objects (POST /api/v2/ontologies/{ontology}/objects/Shipment/aggregate) with a count metric and a where filter of status = late, using only the api:ontologies-read scope. The check passes when this returns the expected late-shipment count (3 in the fixture Ontology). This is the one machine-confirmable fact in the unit—it proves the late-shipment object set the SPA renders is non-empty, so if your table later shows nothing you know it is a code/wiring bug, not empty data. Note that this confirms the Ontology the app consumes; it does not and cannot confirm that your UI renders the rows.

    not startedinstance check

    Confirms the late-shipment object set the SPA renders reproduces via an aggregation.

  3. 3

    Pass the repository checks (lint/test/build)

    MANUAL / self-attested. In the workspace, run the repository checks from the development guide—npm run lint, npm run test, and npm run build—and confirm all three succeed. These are client-side toolchain results: the lint/test/build status of your repository lives in your development environment and is not exposed by any Foundry READ API, so this step is attested by you and reviewed by an instructor rather than confirmed by an automated check. Capture the passing output as your evidence, and treat a green build as the gate before wiring the live object list in the next step.

    not startedself-attested

    Self-attested: npm run lint/test/build succeed per the development guide.

  4. 4

    Render and verify the live object list in the SPA

    MANUAL / self-attested. Run the SPA, complete the OAuth2 Authorization Code redirect to sign in as the current user, and verify the app uses the OSDK client (a Search Objects / list-where read under api:ontologies-read) to render the Shipment object set in a table or list. Frontend rendering and OSDK client wiring are client-side, so no READ API can introspect them—this is an attested step backed by the data check you ran earlier: because that aggregation already proved the late-shipment set is non-empty, a blank table here points to a wiring or code defect rather than missing data. Confirm the list reflects live Ontology data (re-fetching shows current rows) and capture a screenshot of the rendered object set as your evidence.

    not startedself-attested

    Self-attested: the SPA authenticates and shows the Shipment object set in a table/list.