Skip to content
Agile Defense

Curriculum / Frontend & OSDK Developer

INTERMEDIATEUnit 6unit-06

Develop, debug, and iterate in the dev toolchain

not started~240 min
Develop the SPA in a VS Code workspace with live reload, and decide between a cloud workspace and the local Palantir extension.

Introduction

Scenario: Your mission command app on the supply-chain Ontology now reads, searches, aggregates, and writes — but you have been iterating in an ad-hoc setup. You need a reproducible dev toolchain so the team can develop, debug, and live-reload the OSDK React SPA against the Ontology with confidence.

This unit is about how you develop the app, not what new capability it gains. By now the mission command SPA consumes the supply-chain Ontology — Supplier, PurchaseOrder, Shipment, InventoryItem, and DisruptionEvent object types — through a generated OSDK package, the Ontology REST API v2 (Search Objects and Aggregate Objects), Apply Action, and Execute Query. Your goal here is to stand up a repeatable development environment so that editing a React component, saving, and seeing the change against live Ontology data is fast and predictable for every developer on the cohort. This unit assumes a coding-capable audience: you are comfortable in TypeScript/React and an OAuth2 client, and the toolchain choices below are framed for developers, not analysts.

Palantir offers two distinct editing environments, and choosing the right one is the core decision of this unit. In-platform VS Code workspaces are full development environments deployed on Palantir infrastructure (built on Code Workspaces): they auto-configure the environment, integrate directly with Foundry resources, and are well-suited to production-ready OSDK React applications with live reload — when you save a component, the running dev server reflects the change. The local Palantir extension for Visual Studio Code is the opposite model: it installs into a copy of VS Code on your own machine and is the endorsed method for local development of Python transforms, requiring admin enablement and dataset-read permissions. Knowing which environment fits which work — and why an OSDK React SPA generally belongs in a cloud workspace with live reload — is what you document here.

Be clear-eyed about what is and is not verifiable. Almost everything this unit produces is client-side or dev-environment state: the VS Code workspace itself, the live-reload dev server, editor configuration, and your written workspace-vs-extension decision are not exposed by any documented Foundry data READ API, so they are attested rather than machine-checked. The one thing we can confirm programmatically is connectivity: from the workspace, a read against List Object Types (using the api:ontologies-read scope) should resolve the five expected supply-chain object types, which proves the dev environment is correctly authenticated to the Ontology the app consumes. That check validates the plumbing between your toolchain and Foundry — it does not validate the editor, the live-reload server, or your code.

Capability focus: In-platform VS Code workspaces (live reload, Foundry-resource integration); the local Palantir VS Code extension; dev environment auth. · Artifact: A reproducible dev setup with live reload plus a documented workspace-vs-extension decision.

Key concepts

  • VS Code workspaces (in-platform): Development environments deployed on Palantir infrastructure and built on Code Workspaces, intended for production-ready code including OSDK React applications, Python transforms, and compute modules. They provide automatic environment setup and direct integration with Foundry resources, so an OSDK React app can run with live reload against the live Ontology without manual local configuration.
  • Palantir extension for Visual Studio Code (local): An extension installed into a local copy of VS Code that integrates with Foundry for preview, debug, and build workflows. It is the endorsed method for local development of Python transforms, requires admin enablement plus dataset-read permissions, and is distinct from cloud VS Code workspaces.
  • Live reload for OSDK React applications: The cloud VS Code workspace runs the React dev server so that saving a component updates the running app, giving a fast edit-save-observe loop while developing against the Ontology. Rendered output and the dev server are client-side/dev-environment state, not read-API-exposed.
  • Dev-environment authentication and the Ontology REST API v2: The OSDK and the Ontology REST API v2 read paths use a least-privilege token. List Object Types (api:ontologies-read) is a read-only call that returns the available object types; resolving the expected apiNames from the workspace proves the environment is authenticated to the Ontology, separate from any UI or code state.
  • Read-confirmable vs attested surface: The Ontology the app consumes (object types and aggregates) and platform resources are read-confirmable via documented APIs, whereas the VS Code workspace, editor settings, dev server, OSDK package internals, React components, and OAuth2 client configuration are client-side/dev-environment artifacts that no documented Foundry READ API exposes — so they are honestly attested.
  • Least-privilege scoping in development: Read flows in this unit need only api:ontologies-read; the dev environment should not hold broader scopes than the work requires. Over-broad scopes (for example requesting write when only reading) widen blast radius without enabling the development task at hand.

Companion video

VS Code dev toolchain walkthrough (placeholder) · open on YouTube

Hands-on activity

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

    Develop the SPA in a VS Code workspace with live reload

    Develop the mission command SPA inside an in-platform VS Code workspace, which is deployed on Palantir infrastructure (built on Code Workspaces), automatically sets up the environment, and integrates with Foundry resources. Open the workspace, run the OSDK React dev server, and confirm live reload by editing a component (for example a column in the Shipment list) and observing the running app update on save. This step is self-attested: the workspace, its editor state, and the live-reload dev server are dev-environment/client-side artifacts that no documented Foundry data READ API exposes, so there is no programmatic check that you used the workspace — the connectivity proof comes in the final step. Note for this coding-capable cohort that the value is the tight edit-save-observe loop against the live Ontology, not a new app capability.

    not startedself-attested

    Self-attested: the SPA is developed in the in-platform VS Code workspace with live reload.

  2. 2

    Decide workspace vs local Palantir extension

    Write a short, defensible decision on when to use a cloud VS Code workspace versus the local Palantir extension for VS Code. Ground it in the documented distinction: cloud workspaces are deployed on Palantir infrastructure with automatic setup and direct Foundry-resource integration and suit production-ready OSDK React apps with live reload, while the local extension installs into your own VS Code, is the endorsed method for local development of Python transforms, and requires admin enablement plus dataset-read permissions. Conclude with the choice for this app (an OSDK React SPA, which generally belongs in a cloud workspace) and the rationale. This step is self-attested: the choice is human judgment recorded in a document and is not API-verifiable, so the review standard is the quality and accuracy of the reasoning, not a machine check.

    not startedself-attested

    Self-attested: a documented decision on cloud workspace vs the local Palantir VS Code extension.

  3. 3

    Confirm the workspace can reach the live Ontology

    Confirm that the dev environment is correctly authenticated to the Ontology the app consumes by resolving the five supply-chain object types from the workspace. From the workspace, issue a read against List Object Types using the api:ontologies-read scope (the same read path the OSDK and Ontology REST API v2 use) and verify it returns Supplier, PurchaseOrder, Shipment, InventoryItem, and DisruptionEvent, each with a primary key. This is the one read-confirmable check in the unit: it proves the toolchain-to-Foundry connectivity and authentication, not the editor, the live-reload server, or your component code. Keep the dev token least-privilege — api:ontologies-read is sufficient for this read — and do not broaden scopes beyond what the development task needs.

    not startedinstance check

    Confirms the dev environment is correctly authenticated by resolving the expected object types.